Hallo,
Hier gibts noch ein Neues Modul (Bridge und Device) fuer die Milight LED Beleuchtung (Applamp, LimitlessLED, Easybulb usw). Es ist auf die 32_WifiLight.pm von Hermannj basiert und gegrundet, aber Konzentriert nur als VOLL support der Milight Funktions (zb. DiscoMode, Colour Temperature) und sequence automatizierung (zb. readings "transitionInProgress", save/Restore/Last state usw.). Alles ist im Modul Dokumentiert (Entschuldigung, aber nur English).
Here is a new module (Bridge and Device) for the Milight LED lights (sold as Applamp, LimitlessLED, Easybulb etc). It is based heavily on the 32_WifiLight.pm module from Hermannj but concentrates only on the Milight bulbs - implementing all functions (eg. DiscoMode, Colour Temperature etc) and adding helpers for sequence automation (such as save/Restore/Previous state, "transitionInProgress" readings and automatic time calculation of dimup/dimdown when 100% is specified). The modules come with full documentation built-in. I use them every day in my main home automation system.
MilightBridge: https://github.com/mattwire/fhem/blob/master/30_MilightBridge.pm
MilightDevice: https://github.com/mattwire/fhem/blob/master/31_MilightDevice.pm
These modules are now in fhem SVN. Please test :)
Hi,
warum gibt es denn jetzt noch ein Modul?
Warum wird dies nicht zusammen entwickelt und ein Modul dafür gebracht?
Gruss Dirk
Hi,
kriege ne Fehlermeldung :(((
define milight MilightBridge 192.168.xxx.xxx
define Kueche MilightDevice RGBW milight 1
define SZ MilightDevice RGBW milight 2
define Whonzimmer MilightDevice RGBW milight 3
Cannot load module MilightDevice Cannot load module MilightDevice Cannot load module MilightDevice
Log:
2014.12.23 15:49:03 0: Can't locate Math/Round.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/31_MilightDevice.pm line 34, <$fh> line 63.
BEGIN failed--compilation aborted at ./FHEM/31_MilightDevice.pm line 34, <$fh> line 63.
gruß
Ps: cpan install Mathe::Round did the Trick :))) gelöst!! :)
@ roter Stern,
Ein nach dem Blick ins LogFile und etwas Nachdenken hätte es Dir verraten sollen, das da ein perl Modul fehlt. Abhilfe:
sudo apt-get install libmath-round-perl
Übrigens Dank an dem Modulautor, die Sache sieht sehr gut aus. Besonders gefällt mir die feste Kopplung an einen Slot. Da ist das andere Modul bei mehreren RGBW Stripes nicht dauernd am Strom sind mehrmals durcheinander gekommen.
Im Bild oben, werden 8 Slots angezeigt. Welche Bridge soll das sein, meinte irgendwo gelesen zu haben, dass die nur 4 besitzen.
@8PABenny: Hi, mit der bridge v3/4 slot 0 sind fur älterer RGB. 1-4 White und 5-8 RGBW. Ein bridge kann alle dieses Geräte Kontrollieren.
Sie brauchen die Math::Round perl Modul. Ich werde die Dokumentation Aktualisieren! Danke
Also nur zum Verständnis, ich besitze die V4. Kann 4 RGBW Leuchtmittel/Gruppen haben und zusätzlich noch zum Beispiel 4 White?
@8PABenny: Ja, du hast Recht!
Das ist sehr gut. Werde ich die nächsten Tage mal testen.
Habe meine Milights mal auf dieses Modul umgestellt. Läuft gut. ;) Habe aber auch was, was mir negativ auffält. Und zwar gibt es WEBphone keine möglichkeit zum dimmen und das ist meine häufigste Eingabequelle für FHEM. Ansonsten finde ich das mit den Slot-Zuweisungen sehr gut und auch mit dem Colorpicker. Super Modul!
Mein Log gibt auch einen Fehler aus, was aber die Funktion des Moduls nicht beeinträchtigt
PERL WARNING: Use of uninitialized value $args[0] in pattern match (m//) at ./FHEM/31_MilightDevice.pm line 349.
Hallo,
wie funktioniert bei euch das ein- und ausfaden mit zb.
set lampe on 1
Bei mir ist es recht ruckelig/nicht flüssig. Ich hab einen Raspberry Pi als Server am Laufen und es kann natürlich sein, dass es deswegen ruckelt. Ich hab bei dem anderen Plugin (wifilight) heute aber gesehen, dass es dort ein Gamma-Attribut gibt, mit dem man die Linearität und die Abstufungen einstellen kann und damit ein bisschen eingreifen. (das dimmen funktioniert ja flüssig, also zb. von 100 auf 10%)
Habt ihr da ein paar tips, wie ich da etwas verbessern kann? Gibt es Möglichkeiten dafür ohne neue Hardware zu besorgen? Und wenn nichts daran vorbei führt: was könnt ihr empfehlen? (ist ja alles recht speziell, weil es ja kein.. Multitasking (?) in FHEM gibt, die Hardware also vermutlich umso besser sein muss um das auszugleichen und der Server aber trotzdem nicht so viel strom fressen soll)
Btw: Danke @mattwire für die Entwicklung! :)
Hi,
erst mal vielen Dank für das Modul, funktioniert wirklich gut :).
Eine Bitte habe ich noch. Wenn die Lampe aus ist, wird das DevStateIcon in schwarz dargestellt, was auf einem dunklen Hintergrund nicht wirklich sichtbar ist ;).
Könntest du das ggf. so implementieren, dass das Icon im ausgeschalteten Zustand in weiss (am besten ohne die Strahlen (light_light))dargestellt wird?
Dank dir!
Zitat von: dennis87 am 03 Januar 2015, 22:46:08
Eine Bitte habe ich noch. Wenn die Lampe aus ist, wird das DevStateIcon in schwarz dargestellt, was auf einem dunklen Hintergrund nicht wirklich sichtbar ist ;).
Könntest du das ggf. so implementieren, dass das Icon im ausgeschalteten Zustand in weiss (am besten ohne die Strahlen (light_light))dargestellt wird?
Dank dir!
Dann gibt es aber bei denen ein Problem die einen weißen Hintergrund haben. ::)
Dann wäre hier eine css Class gut (z.B. die normale SVG Class) .. Dafür einfach keine Farbe setzen ;)
Hat noch wer das problem, dass immer wieder (alle paar stunden einmal) das licht kurz blau wird und dann wieder normal?
Da meine 2 Leuchtmittel am Wochenende ca 3 bis 5 Stunden an sind, kann ich sagen, dass ich das Phänomen bei mir noch nicht beobachten konnte.
Zitat von: Schrottpresse am 14 Januar 2015, 08:35:10
Hat noch wer das problem, dass immer wieder (alle paar stunden einmal) das licht kurz blau wird und dann wieder normal?
ist das nur eine Birne oder alle?
was ist bei dir normal? weiß?
Ich hatte mal eine defekte 9w birne da ist der Grünkanal immer ausgefallen also wenn es gelb sein sollte war nur noch rot da und eine 5w da ging das rot nicht mehr. Kann also auch dir Birne sein
Wenn es von Fhem kommen sollte, könnte ja auch was im Logfile stehen.
Unterscheidet sich das Modul beim Dimmen und Farbwechsel von Wifilight oder macht es da genau das selbe? Geht mir speziell um ruckelfreies dimmen, dass der LD382 z.B. nur über die eigene App zuverlässig kann.
Der LD382 gehört nicht zur Milight Familie, daher denke ich, dass das Modul wahrscheinlich nicht damit funktionier :-\
Hi, Dieses Modul sind nur für Milight entwickelt. Für die Ld382 können Sie das Wifilight Modul nutzen. Danke
@mattwire
Funktioniert das Modul eigentlich auch mit dem WRGB (FUT028) Controller?
Does the module work with the WRGB(FUT028) controller?
http://forum.fhem.de/index.php/topic,18958.msg212551.html#msg212551
Es gibt leider noch Erweiterung der App dafür. Also kein Pairing mit der Bridge möglich :(
They didn't added an extentional control view in the app yet. So no pairing with the brigde at the moment :(
Zitat von: Blackcat am 14 Januar 2015, 11:53:39
Der LD382 gehört nicht zur Milight Familie, daher denke ich, dass das Modul wahrscheinlich nicht damit funktionier :-\
Den LD382 hab ich nur als Vergleich genommen. Falls das Dimmen mit diesem Modul besser funktioniert, würde ich den LD382 gegen einen MiLight Controller austauschen.
Ich kann das gerne mal für dich testen, habe meine "normalen"(ohne Sättigung) RGBW Controller (FUT038) im Moment mit Wifilight laufen, kann aber auch mal mit diesem Modul testen.
Wie genau soll es denn dimmen?
PS:
hier ist der Unterschied zwischen den beiden Milight Controller erklärt:
http://futlight.en.alibaba.com/product/60034266477-210737841/mi_light_wifi_control_Automatic_Group_Synchronization_RGBW_led_strip_controller.html
Habe den FUT038 also den normalen milight rgbw controller ohne Probleme am Laufen
der FUT028 ist noch sehr neu und hat noch keine App Erweiterung (oder ich bin zu blöd zum Pairen), habe nur gesehen es gibt jetzt eine neue Android App die probiere ich nachher mal aus :)
Ideal wäre 20-24 Stufen pro Sekunde. Auf bestimmte Prozentwerte zu Dimmen ist mir nicht ganz so wichtig. Mir geht es hauptsächlich um kurzes Dimmen von 0 auf 100% in 1-3 Sekunden zum eleganteren An- und Ausschalten. Bei diesen kurzen Zeiten ruckelt der LD382 (vermutlich auf der FUT038) mit WifiLight und es können Dimmstufen übersprungen werden. Das soll wohl daran liegen, dass WifiLight nicht nur für einen bestimmten Controller entwickelt wurde und so z.b. auch nicht die Graduate Funktion aus der App benutzt werden kann, bei dem der Controller selbst den Dimmvorgang ruckelfrei übernimmt. So wie ich es verstanden habe, nutzt Wiflight den ramp Befehl, der für das zeitgesteuerte Dimmen nicht umbedingt ideal ist, da die Dimmwerte einzeln übertragen werden.
also das was die Philips Hue immer machen :)
ich prüf das mal mit beiden Modulen und dem FUT038, weiß aber noch nicht ob ich es heute noch schaffe
Servus,
ich habe ein Problem mit dem Modul wenn ich den DIMUP xx Befehl benutzen möchte.
Vorhaben: Lampe von 0 -> x hochdimmen in 600 sekunden (um morgens aufzuwachen).
Beispiel: set schlafzimmer.licht.kugel dimup 24 600
Problem: es wird immer vor dem Hoch-Dimmen der Status auf den letzen Zustand brightness_on gesetzt, was
erstmal dafür sorgt das die Lampe Vollgas bekommt. Ein "sanftes" Wecken geht so nicht.
Was kann ich tun?
Gruß
Harry
also ich nutze das wifilight modul, da aber das milight daraus entstanden ist vermute ich das es ebenso funktionieren dürfte..
schicke mal bevor du DIMUP machst einen HSV Befehl mit Helligkeit 0. danach solltest du die farbe langsam hochdimmen können...
und danach einfach mit set LAMPE DIM 24 600
und nicht mit DIMUP.
Bei Wifilight schaltet DIMUP immer einen festen wert hoch.
Bei DIM wird der Wert 24 in 600sek erreicht und somit langsam hochgedimmt...
Zitat von: Blackcat am 14 Januar 2015, 09:02:30
ist das nur eine Birne oder alle?
was ist bei dir normal? weiß?
Ich hatte mal eine defekte 9w birne da ist der Grünkanal immer ausgefallen also wenn es gelb sein sollte war nur noch rot da und eine 5w da ging das rot nicht mehr. Kann also auch dir Birne sein
Hallo, danke für die Antwort - ich war leider weg und habs dann erst jetzt gesehen.
Es ist immer Kanalweise, also beispielsweise die zwei Lampen in der Küche die über einen Kanal laufen oder die Lampe im Schlafzimmer. Die Farben funktionieren sonst alle.
Teilweise bleibt es dann blau bis das nächste "Bewegungsmelder-Update" kommt, teilweise ist es nur wie ein flackern. Im Logfile hab ich mit verbose 3 mal nichts bemerkt - ich kann aber mit v5 noch einmal probieren und beobachten.
Ich habe die Limitless RGBW 9V Birnen auf 2 Bridges laufen und sie sind indirekt mit HM-Bewegungsmeldern verknüpft (wenn Bewegung ist wird der entsprechende Kanal für 3 minuten auf on gestellt).
@scubao. Das ist eine Begrenzung der milight Birne. Es gibt ein Hardware Helligkeitsspeicher im Birne. Wenn Sie möchten kein "flash" dann schick ein Set Lampe dim 4(oder Minimal) vor der Set Lampe off. Schlecht weiß ich aber das ist so.
Hi mattwire,
recent versions of wifilight adresses that issue in a way of inserting the lowest possible brightness before switching off. That feature is added after you forked it, so you may want to have a look.
regards
joerg
@matt @hermannj thanks for highlighting the issue. I switched to wifilight and i haven't seen that flash again.
Here's some additions, please test and update the code:
-
Hue set/transition, set with command
hue -
Saturation set/transition, set with command
saturation- Bugfix for long transition on hue=0 and hue = 360
- Attribute
defaultStartupDim for setting hadware brightness before OFF
(set to 4 for most MiLight bulbs to get rid of any
"flash" problems)
- Minor code improvements (query reorder as nobody really uses RGB bulbs)
-
Documentation for additions
;) Markus
Zitat von: herrmannj am 20 Januar 2015, 19:51:56recent versions of wifilight adresses that issue in a way of inserting the lowest possible brightness before switching off.
Hab ich im Code auf die Schnelle nicht gefunden. Wie hast du's denn gemacht?
Hallo ihr Lieben,
ich habe die Mi-Light Bridge soweit eingebunden bekommen ohne Fehler.
Ich habe via Fernbedienung eine E27 9W Birne auf den Slot "3" gelegt, die Birne kann ich auch
über die Fernbedienung steuern (komischerweise nicht über die iPhone App).
Wenn ich nun ein Milight Device definieren will mit:
define milighttest MilightDevice RGB MiLightBridge 3
bekomme ich:
Invalid slot: Select 0 for RGB
Ich kann den Fehler leider nicht finden.
Kann mir jemand weiterhelfen ?
Liebe Grüße,
Patrick
Ich vermute mal dass Fernbedienung und Bridge nichts miteinander zu tun haben.
Lern die Birne nochmal mit der App an, dann sollte das klappen.
RGBW, außerdem.
Hallo,
@Patrick:
hast Du auch das eigentliche Device angelegt ? Z.B. so
define Milight MilightBridge 192.168.1.25
attr Milight alias Milightbridge
attr Milight event-on-change-reading state
attr Milight port 8899
attr Milight sendInterval 100
und dann die Lampe (rgbw2 ab Slot 7) - Die Slots sind für verschiedene Lampentypes "reserviert"
define Milightlamp3 MilightDevice RGBW Milightbridge 7
attr Milightlamp3 IODev Milight
attr Milightlamp3 devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
attr Milightlamp3 event-on-change-reading state,transitionInProgress
attr Milightlamp3 room Arbeitszimmer
attr Milightlamp3 webCmd rgb:rgb ffffff:rgb ff2a00:rgb 00ff00:rgb 0000ff:rgb ffff00:on:off:dim
VG
Karl
Leider hilft mir das nicht weiter.
Ich habe natürlich die Bridge richtig definiert und das Device auch.
Ich habe jetzt die Birne mit der iPhone App gepairt.
Eine normale E27 9W Birne auf den Slot "3"
Wenn ich das Device nun richtig definiere kommt immer noch:
Invalid slot: Select 0 for RGB
Gruß,
Patrick
@nocomment: Eine normale 9W-das ist ein RGBW? Dann nutzen Sie Slot5-8 und RGBW type
@hermannj: Danke, ich werde gucken
@markusm: Danke für Die neue Funktionen. Ich werde im Abend prüfen.
Vielen Dank mattwire!
Das war es.
Zitat von: kennymc.c am 14 Januar 2015, 15:09:27
...Mir geht es hauptsächlich um kurzes Dimmen von 0 auf 100% in 1-3 Sekunden zum eleganteren An- und Ausschalten. Bei diesen kurzen Zeiten ruckelt der LD382 (vermutlich auf der FUT038) mit WifiLight und es können Dimmstufen übersprungen werden....
Zitat von: Blackcat am 14 Januar 2015, 15:24:15
also das was die Philips Hue immer machen :)
ich prüf das mal mit beiden Modulen und dem FUT038, weiß aber noch nicht ob ich es heute noch schaffe
Hat das mittlerweile schon jemand testen können?
@MarkusM: Danke fuer die Patch.
- Hue set/transition, set with command hue:
I already added this last week along with a "preset" function.
- Saturation set/transition, set with command saturation:
Thankyou, I set the slider 0,100,100 because those are the only supported values.
- Bugfix for long transition on hue=0 and hue = 360
Thankyou
- Attribute defaultStartupDim for setting hadware brightness before OFF
(set to 4 for most MiLight bulbs to get rid of any "flash" problems)
Thanks, I hardcoded this so it does it automatically, and uses MilightDevice_dimSteps to get minimum for each lamp type.
- Minor code improvements (query reorder as nobody really uses RGB bulbs)
Thankyou
- Documentation for additions
Thankyou
Hallo,
was genau bewirkt das "Hue"-Commando bei den Milights?
Gruss
Thommy
Ändert die Farbtemperatur, d.h. du musst nicht das komplette HSV Kommando absetzen.
Ist in erster Linie interessant für einen Farbslider.
Zitat von: mattwire am 29 Januar 2015, 23:46:04- Attribute defaultStartupDim for setting hadware brightness before OFF
(set to 4 for most MiLight bulbs to get rid of any "flash" problems)
Thanks, I hardcoded this so it does it automatically, and uses MilightDevice_dimSteps to get minimum for each lamp type.
Thanks! This needs more work, though:
We need to check if the device is still on and only then do the set to minimum.
Otherwise we'll have a short flash when we try to turn off a lamp that's already off.
This shouldn't really happen but it will. I'll do some testing tonight.
@markusm: already fixed ☺ check the latest svn
Hey, i received the new RGBW milight Controller today that can change saturation per color.
Can this be paired also via this module ?
The difference is that the other Controllers can have multiple Zones. This one apparently not.
Thanks for the help.
This sounds a lot like the old RGBW1 controller. Try accessing it on slot 0.
Can you share where you got it?
Do you have a Fut028 (wrgb)? I have two of them at home.
I am Testing this Controller with fhem with Wifilight, if you can read German this may be interesting for you:
http://forum.fhem.de/index.php/topic,18958.msg255123.html#msg255123
Ja es ist ein Fut028 Kontroller. Ja ich kann deutsch ;-)
Hab nur englisch geschrieben wegen dem Post vorher.
Gekauft habe ich es bei ebay bei Gadgetsandmore.
Ich schreib hier auch nur Englisch dass Matt leichter mitlesen kann ;)
Vom Aufkleber her sieht das aus wie der alte RGBW1 Controller.
Hast du ihn schon mal als solchen mit WifiLight eingebunden?
ne, der ist neu und benötigt eine komplette bridge für sich alleine. Wenn jemand raus findet wie man den zum weiss-und-color gleichzeitig machen bekommt ohne über die steps zu gehen können wir den auch einbinden. Sandra hat ja schon viel dazu raus gefunden.
Ich kann (woanders ;) ) einen Test einbauen. Im Protokoll gibt es auch noch einige bisher unbenutze sequenzen die das vielleicht sind - nur ohne so ein Ding in der Hand zu halten um das zu testen ist das eine Qual.
vg
jörg
Er verhält sich aber anders, jede Farbe wird als Zone erkannt. Also wie RGBW2 nur ist an / aus -> dimUp / dimDown, habe ihn deshalb "teilweise" mit Wifilight am Laufen.
Als RGBW1 hatte er ihn nicht erkannt.
ne, die RGBW1 haben ein ganz anderes Protokoll. Für den FUT028 haben die das bestehende Protokoll einfach recycelt - sicher um mit den bestehenden bridges kompatibel zu bleiben. Aus dem Verhalten das Du (@Sandra) beschrieben hast kann ich mir auch einen Reim machen. Der Punkt sind die RGBW Mischung die nach Deiner Beschreibung ja nur über "hoch" "runter" geht. Da müsste das Modul immer mit zählen. Wenn jetzt irgendwann ein einziger Befehl nicht bei dem controller ankommt stimmt die Zählung nicht mehr - und das was beim RGBW1 nach Zeit xxx immer ein echt störender Punkt. Ich hoffe mal das "die" (chinesen) doch noch einmal um die Ecke gedacht haben und da was eingebaut haben. Sonst taugt der für automatische Ansteuerung einfach nicht ... da braucht man nicht lange drum rum reden .
vg
jörg
kacke , ok , im endeffekt heisst das dass es nix wird, ausser ich hab noch einen 2ten wifi Kontroller. weil auch wenn ich Wifilight nutze, dann geht der andere Kontroller ja nicht mehr , habe ich das richtig verstanden ?
Yepp!. ...leider.
(btw In wifilight ist der fut028 auch noch nicht drin)
der normale RGB Wert ohne Sättigung lässt sich wie bei dem normalen RGBW2 setzten, deshalb habe ich noch Hoffnung. Wenn nicht muss eben doch ein UFO her ;)
die muss ich Dir nehmen, ich kenn das Protokoll der RGBW2. Der fut028 braucht die ganze bridge. Was mich interessieren würde. Wenn Du (Ihr) auf der bridge 4 x RGBW2 einrichtest, kannst Du dann mit jeder der vier die Farbe auf dem fut028 setzen oder nur mit der ersten ?
Ja, mit allen 4.
Hallo ich bin der 'Neue' in de Runde :)
Nachdem ich in den letzten Wochen / Monaten dank des PDF, diesem Forum und anderen Seiten nach und nach alles irgendwie ans Laufen gebracht habe muss ich nun doch mal nachfragen.
Ich hoffe natürlich das ich keine unsinnige Frage stelle die schon x mal beantwortet worden ist, wenn ja dann seid bitte nachsichtig und schickt mich nicht in die Wüste ;D
Ich habe hier nach und nach vier MiLight Bridges konfiguriert und in FHEM eingebunden. Das funktioniert nun auch soweit mit dem MiLight Modul.
Einen MiLight RGBW 4-Zonen Controller habe ich auch erst mit der MiLight App an eine Bridge angelernt und konnte diesen auch in FHEM über Slot 5 einbinden.
Wenn ich nun einen weitern 4-Zonen RGBW Controller an der gleichen Bridge anlerne in Zone 2 - welcher Slot ist das dann? Irgendwie bin ich grad zu vernagelt das zu begreifen oder ich finde einfach die Lösung da(z)u nicht..
Eine weitere Bridge habe ich mit MiLight RGB 4-Zonen Controller über die App gepairt. Mit der App auf dem Androiden kann ich sie auch komplett ansteuern, aber in FHEM komme ich wieder an meine Grenzen.
Bei der Definition des MiLight Devices ist der Typ ja RGB und nicht RGBW, somit muss der Slot 0 sein. Das habe ich auch angegeben, allerdings bringt mir das keinerlei Funktion.
Was mich auch wieder zu der Frage bringt:
Wie adressiere ich Zone 1-2-3-4 in FHEM? Sehe ich den Wald vor lauter Bäumen nicht oder ist das Modul einfach noch gar nicht soweit und lauf ich deswegen gegen die Wand? :o
Für sachdienliche Hinweise bin ich jederzeit dankbar ;)
Gruß
Mario
EDIT: Hab den den Baum im Wald gefunden *seufz* hab mein Problem also gelöst bekommen :)
Hi Matt, another bug report here:
For me, Colorpicker for CT seems to just totally ignore the values you set for sliders and defaults to 2800-6300
So maybe we should just go with these values?!
I was also wondering why the WW strip never turned off - it seems there are actually 11 values for color temperature, including 0.
# Couldn't get switch statement to work so using if
if ($ct < 4550) {
if ($ct < 3150) { return 10; }
if ($ct < 3500) { return 9; }
if ($ct < 3850) { return 8; }
if ($ct < 4200) { return 7; }
return 6; # (< 4550)
} else {
if ($ct < 4900) { return 5; }
if ($ct < 5250) { return 4; }
if ($ct < 5600) { return 3; }
if ($ct < 5950) { return 2; }
if ($ct < 6300) { return 1; }
return 0; # (>= 6300)
}
;) Markus
There should only be 10 ct values according to the api (1-10). You should not be able to turn off using ct!
I think there may be a bug in the slider - 3000-6500 are the correct limits but they are changing in fhemweb :-(
Zitat von: mattwire am 20 Februar 2015, 09:04:14
There should only be 10 ct values according to the api (1-10). You should not be able to turn off using ct!
I think there may be a bug in the slider - 3000-6500 are the correct limits but they are changing in fhemweb :-(
At the minimum and maximum CT values, one of the strips should be off.
With my controller I could only achieve this by using 11 values.
Maybe the correct values are 0-9, but to me it seems 11 is the way to go.
Do you have a WWCW device to test this?
@MarkusM:
I have a 6W E22 White lamp for testing.
There are no direct values for setting colourtemperature, only up/down. The API says:
3E 00 55 - Warmer
3F 00 55 - Cooler (There are ten steps between warmest and coolest)
Are you using a LED strip controller? Then you may be able to see the number of steps more clearly. Can you confirm if your are certain that it is 11 steps and not 12?
Zitat von: mattwire am 22 Februar 2015, 20:38:30There are no direct values for setting colourtemperature, only up/down. The API says:
3E 00 55 - Warmer
3F 00 55 - Cooler (There are ten steps between warmest and coolest)
If you define a step as the transition between two values, that's actually technically correct :)
I can confirm that there are 11 values for color temperature on my strip controller.
There are also 11 values total for brightness.
Can you add my code for color temperature and take care of the brightness?
@MarkusM: Please test the attached changed for ct and dim 11 steps for White
Zitat von: mattwire am 22 Februar 2015, 22:31:50
@MarkusM: Please test the attached changed for ct and dim 11 steps for White
Can't really test it comfortably because of the CT slider values.
You need to change that to 2800-6300, otherwise the UI is just a mess.
Setting CT manually it's like before (warm still on at 6500) - but you used values 1-11 while I used 0-10?!
dim still has 10 steps for me in the slider.
Zitat von: Markus M. am 22 Februar 2015, 22:49:23
Can't really test it comfortably because of the CT slider values.
You need to change that to 2800-6300, otherwise the UI is just a mess.
3000-6500 is correct. There is a bug with the slider in fhemweb (http://forum.fhem.de/index.php/topic,34230.0.html)
Zitat
Setting CT manually it's like before (warm still on at 6500) - but you used values 1-11 while I used 0-10?!
The values are irrelevant since the API does not support direct setting of CT, only +/-. So 1-11 are only used internally for tracking state.
Zitat
dim still has 10 steps for me in the slider.
Did you restart fhem?
Tried again, seems to have been a problem with reloading.
CT kind of works. For some reason the slider now shows me 2880-6400?
Please make the following changes for error handling around the extremes and remove unnecessary comparisons:
...
if ($ct < 3320) { return 11; }
elsif ($ct < 3640) { return 10; }
elsif ($ct < 3960) { return 9; }
elsif ($ct < 4280) { return 8; }
elsif ($ct < 4600) { return 7; }
elsif ($ct < 4920) { return 6; }
elsif ($ct < 5240) { return 5; }
elsif ($ct < 5560) { return 4; }
elsif ($ct < 5880) { return 3; }
elsif ($ct < 6200) { return 2; }
return 1;
Dim seems fine, apart from there not being a value of 100 on the slider :)
Thanks & good night!
Markus
Ok, dimming white strips is not fine :(
There are some serious issues with brightness at the moment.
Sometimes the strip is at > 50% brightness but thinks it's on the lowest level.
The only thing that helps is to set it to 100% and then dim down again.
It's probably due to lost packets and/or a hardware and software brightness mismatch.
What could help:
Can you change the logic so that On/Off for white bulbs is completely handled by dimup/dimdown commands and for values of 0% and 100% a few more down/up packets are sent, just for good measure?
Hi, dimming works perfectly here. Can you try moving the bridge closer to the white strip?
The API provides commands for dimup, dimdown, on, off, fullOn. I use the fullOn command for 100% that is why it is resetting it for you. If you changed to use only dimming commands then it would not be possible to turn on instantly at the last brightness.
Matthew
By the way, slider min/max is now fixed: http://forum.fhem.de/index.php/topic,34230.0.html
Hi ich nutze Milight 6w Bulbs und die bieten per app einen night mode durch längeres on drücken, kann ich diesen modus auch mit diesem modul aktivieren?
Hallo speex, RGB oder RGBW?
Nutze, RGBW.
Und eine kleine korrektur da der gewünschte modus durch längeres halten der off taste erreicht wird und nicht durch on.
Danke, ich werder mal schauen
Moin zusammen,
ich teste gerade meine V4-Bridge in Verbindung mit zwei GU10 RGBW Bulbs (http://www.milight.com/milight-gu10-rgbw-spotlight-iphone-ios-android-controlled-light/). Habe die Lampen nun gemäß original Milight-Anleitung mit der Bridge per Android-App mit der ersten Zone gesynct. Die Lampen lassen sich per App auch prima steuern.
Auf meinem PI, auf dem FHEM läuft, habe ich ,,libmath-round-perl" nachinstalliert und die Bridge wie folgt definiert:
define Interface_MilightBridge MilightBridge 192.168.XXX.XXX
Status von Interface_MilightBridge ist auch ,,ok". Also die Verbindung scheint zu bestehen.
Die Zone der Bridge habe ich dann so definiert:
define Licht_Garten_Haustuer MilightDevice RGBW Interface_MilightBridge 5
Auch soweit nix im Log zu sehen. Aber steuern kann ich die Lampen über FHEM nicht. Es passiert einfach gar nichts. Habe ich irgendwas vergessen?
Danke und Gruß,
jahife
Night Mode gibt es nur bei der V4 Bridge.
Die hat außer euch beiden niemand. Ich habe nicht mal ne Bezugsquelle gefunden...
Postet doch bitte mal wo ihr die her habt.
Was macht die Funktion eigentlich genau?
Ich habe sie bei LIGHTEU über amazon bezogen, von hier: http://goo.gl/55evLh (http://goo.gl/55evLh) alternativ nur die Bridge http://goo.gl/YdnWzg (http://goo.gl/YdnWzg)
Der Night mode lässt sich durch etwas längeres drücken der aus taste ansteuern und dimmt die lampe extrem runter und schafft so ein wirklich angenehmes nacht licht.
Ich hab schon probiert es händisch mit fhem so weit runter zu dimmen aber die nierigste dimm stufe ist immer noch viel heller als das was der night mode kann.
Ansonsten kann ich noch über die master an/aus Knöpfe in der app, alle zonen gleichzeitig synchronisiert ansprechen ist das auch mit dem modul möglich?
Danke für den Tipp mit dem NightMode - hatte ich gar nicht mitbekommen, aber funktioniert mit der 'normalen' Fernbedienung ;)
PS: Bezugsquelle war bei mir AliExpress - dauert zwar eine Weile, dafür unheimlich günstig - ne WiFi Bridge zwischen 14-15€
Zitat von: jahife am 02 März 2015, 12:07:36
Auch soweit nix im Log zu sehen. Aber steuern kann ich die Lampen über FHEM nicht. Es passiert einfach gar nichts. Habe ich irgendwas vergessen?
Danke und Gruß,
jahife
Habe mein Problem noch gefunden. Ich hatte ein IP-Adresskonflikt - hat sich somit erledigt. Ansonsten läuft das Modul super!
Im Anhang:
Night Mode für RGBW Birnen, zu setzen über HSV x,0,1
Strips unterstützen den Modus leider nicht, die weissen Birnen muss ich mir noch ansehen.
Kann bitte jemand mit der aktuellen und meiner Version testen, ob die niedrigsten Helligkeitsstufen (4) gleich sind?
Neue Version etwas weiter unten
Hi danke, der night mode läuft.
Die helligkeitstufen (4) sind nicht gleich, ich würde behaupten das mit der aktuellen Version aus dem SVN die niedrigste helligkeits stufe ein bisschen heller ist als die in deiner modifizierten version,
dann hab ich das ganze nochmal mit der mitgelieferten kleinen weißen fernbedienung verglichen und festgestellt wenn ich mit deiner version die niedrigste helligkeitsstufe an dimme ist das eigentlich die gleiche wie die niedrigste auf der kleinen weißen Fernbedienung, mit der aktuellen version aus dem SVN kann man auch hier beobachten das die fernbedienung noch einen ticken dunkler dimmen kann.
Aber ich würde ja sagen das dass verhalten deiner modifizierung genau richtig ist im vergleich zur physischen fernbedienung.
Danke für's Testen, dachte ich mir fast ;)
Night Mode für Weiss ist auch schon mit drin, und im Gegensatz zu den RGBW Strip Controllern unterstützt der WWCW Strip den Modus ebenfalls.
Meine aktuelle Implementation ist allerdings noch sehr verbesserungswürdig, weil durch die ganze Dim- und Schaltlogik anschliessend alles drunter und drüber geht.
Wahrscheinlich wäre es am besten, wenn der Night Mode einen eigenen Zustand neben on/off bekommt.
@matt
I'll try to implement night mode as a separate state.
Dimming for RGBW didn't use the lowest setting, I fixed that as well.
Hi der Vorschlag den Night mode als eigenen Zustand zu definieren gefällt mir auch.
Kann es sein das du die neue Version weiter unten vergessen hast? :)
Zitat von: speex am 06 März 2015, 23:07:33Kann es sein das du die neue Version weiter unten vergessen hast? :)
Ne, hat mir nur noch nicht gefallen bzw. war noch nicht fertig.
Der Night Mode ist ja auch nicht alles was ich noch eingebaut habe ;)
UPDATE:- Night mode als eigener state
night- Farbkorrektur für HSV über
colorCast- Gruppenschaltung über Slot 'A' für RGBW und White, wahlweise State-Vererbung über
updateGroupDevices- 'DimMode' für White über
dimOffWhite um State-Fehler bei der Helligkeit und Farbtemperatur zu verringern
- Error State verhindert jegliche Zustandsänderungen, wenn die Bridge nicht erreichbar ist
- Starthelligkeit bei unbekanntem Zustand / Fehlern, die über
defaultBrightness gesetzt werden kann
- Weissumschaltung mittels white/toggleWhite bei gleichbleibender Helligkeit für RGBW
- Farbumschaltung automatisch bei Veränderung des hue Wertes für RGBW
- zahlreiche Bugfixes und VerbesserungenBitte Testen und Bescheid geben ob alles passt.
Markus
Hey, klasse habs gerade nochmal getestet läuft echt wunderbar.
- Night mode - läuft.
- Farbkorrektur - Kann ich leider nicht beurteilen (Um ehrlich zu sein weiss ich nicht was ich damit so genau bewirke, und wie es funktioniert)
- Gruppenschaltung - läuft auch allerdings bei den updateGroupDevices ist mir ein komisches verhalten aufgefallen grundsätzlich scheint es zu funktionieren, wenn ich den master schalter betätige werden die states entsprechend gesetzt schalte ich dann aber erneut eine andere farbe kriegen die einzelnen zonen lampen das nicht mit (wenn ich dann zusätzlich den master nochmal dimme sehe ich das auch sie richtig gesetzt werden) , lade ich die Seite manuell mit f5 neu dann sind alle richtig gesetzt. (ja ich weiss nörgeln auf hohem niveau :))
- 'DimMode' für White - Kann ich leider auch nicht beurteilen hab es gesetzt sehe aber keinen unterschied, sollte ich?
vg und danke soweit!
Zitat von: speex am 07 März 2015, 18:59:00
- Farbkorrektur - Kann ich leider nicht beurteilen (Um ehrlich zu sein weiss ich nicht was ich damit so genau bewirke, und wie es funktioniert)
Auf dem Slider siehst du Rot, Gelb, Grün, Cyan, Blau und Magenta.
Die "Position" jeder dieser Farben kannst du mittels der 6 Korrekturwerte verschieben, und damit deine LEDs bei Bedarf an die Farben auf dem Slider und auch untereinander anpassen.
Das klappt natürlich leider nicht bei der Gruppenschaltung.
Zitat von: speex am 07 März 2015, 18:59:00
- Gruppenschaltung - läuft auch allerdings bei den updateGroupDevices ist mir ein komisches verhalten aufgefallen grundsätzlich scheint es zu funktionieren, wenn ich den master schalter betätige werden die states entsprechend gesetzt schalte ich dann aber erneut eine andere farbe kriegen die einzelnen zonen lampen das nicht mit (wenn ich dann zusätzlich den master nochmal dimme sehe ich das auch sie richtig gesetzt werden) , lade ich die Seite manuell mit f5 neu dann sind alle richtig gesetzt. (ja ich weiss nörgeln auf hohem niveau :))
Standardverhalten von FHEM. Wenn du
hue bei
event-on-change-reading einträgst, wird der Slider sofort aktualisiert ;)
Zitat von: speex am 07 März 2015, 18:59:00
- 'DimMode' für White - Kann ich leider auch nicht beurteilen hab es gesetzt sehe aber keinen unterschied, sollte ich?
Im Idealfall nicht, das ist nur dafür gedacht wenn Probleme bei der Ansteuerung der Lampen auftreten.
Bei mir stimmen die Werte für Helligkeit und Farbtemperatur z.B. sehr oft nicht zwischen FHEM und der Lampe überein.
Bei RGBW ist das kein Problem da alles absolut gesetzt werden kann, bei White ist mit dieser Funktion aber zumindest nach jedem An/Aus wieder alles synchron.
Du kannst die Datei nochmal runterladen, hab versucht das mit dem Zustand zu verbessern und die Standard-Helligkeit in ein Attribut gepackt.
Hi
danke für die Tipps mit der Farbkorrektur das werd ich mir noch mal in ruhe näherbringen und damit rumspeielen.
Ansonsten:
UpdateGroupDevices läuft bei mir jetzt einwandfrei, auch ohne das event-on-change-reading hue attribut. Werte werden sofort korrekt gesetzt.
Error State krieg ich nicht reproduziert hatte bisher auch scheinbar noch nicht den fall.
Der defaultBrightness wert wird bei mir nicht beachtet, hängt das mit dem error State zusammen?
Zitat von: speex am 08 März 2015, 15:48:14UpdateGroupDevices läuft bei mir jetzt einwandfrei, auch ohne das event-on-change-reading hue attribut. Werte werden sofort korrekt gesetzt.
Sehr schön.
ZitatError State krieg ich nicht reproduziert hatte bisher auch scheinbar noch nicht den fall.
Kannst du testen indem du die Bridge absteckst, etwas wartest und dann versuchst zu schalten.
ZitatDer defaultBrightness wert wird bei mir nicht beachtet, hängt das mit dem error State zusammen?
Der Wert wird auch nur verwendet wenn intern irgendwas komplett schief geht.
Matt hatte hardcoded 100% drin, bei Nachtlichtern ist das aber nicht gerade zielführend...
Ist der Dimlevel im on-STATE des MilightDevice eigentlich eine Notwendigkeit? Diese Zusatzangabe fällt mir immer wieder auf die Füße, wenn es irgendwo um einfache Schaltmöglichkeiten geht, bzw. die Interpretation des Schaltzustandes geht. Nicht dass das ein unmöglich zu lösendes Problem sei, aber es macht viele Dinge sehr komplex.
Zitat von: nesges am 09 März 2015, 14:10:09
Ist der Dimlevel im on-STATE des MilightDevice eigentlich eine Notwendigkeit?
Gib dich nicht auf, lerne RegEx ;)
Im Ernst, ich seh die Notwendigkeit eigentlich auch nicht, "night" ist dann aber ja ein noch grösseres Problem.
Hast du Vorschläge?
Ich bin aber eigentlich fast der Meinung, dass du falsch programmierst:
Grundsätzlich auf
$state ne "off" zu setzen ist sehr viel besser und sollte immer funktionieren.
Es gibt ja nicht nur An/Aus Geräte sondern auch Dimmer etc.
Viele Grüße, Markus
Zitat von: Markus M. am 11 März 2015, 16:54:20
Ich bin aber eigentlich fast der Meinung, dass du falsch programmierst:
Ein häufiges Problem bei Annahmen ist ja, dass sie falsch sind :) Dass ich darin kein unlösbares Problem sehe, hatte ich ja bereits geschrieben. Im eigenen Code ist's einfach nur eine lästige Kleinigkeit; wenn man aber Code von Dritten verwenden möchte ist's stellenweise echt ätzend. Von daher frage ich mich, ob das irgend einen Benefit hat, oder einfach ersatzlos gestrichen werden könnte. Falls nicht, kein Beinbruch.
Ich hab davon nichts, du auch nicht, aber vielleicht verwendet es ja irgendwer.
Der einzige Vorteil der mir grade einfällt ist der, dass man nur ein Notify für State und Brightness braucht.
Zitat von: Markus M. am 12 März 2015, 14:10:31
Der einzige Vorteil der mir grade einfällt ist der, dass man nur ein Notify für State und Brightness braucht.
Da braucht man eh nur eins, weil ein Update von brightness kein Event auslöst ;-)
Hi,
wenn ich mich nicht täusche, gibt es einen Bug mit der Transitionsdauer und dem Queue-Flag.
Beispiel: Wenn ich folgende Kommandos losschicke
set test hsv 180,100,100 (blau setzen)
set test hsv 120,100,100 60 (Trans. nach grün)
set test hsv 240,100,100 120 q (Trans. nach violett)
Läuft zunächst eine Transition nach grün (erwartet) anschließend wird aber direkt auf violett umgeschaltet (Transition erwartet)
Geräte:
Bridge v4
RGBW Leuchtmittel
Cheers, Jörg
Nutze ich nicht wirklich, kann ich mir aber bei Gelegenheit mal ansehen.
Daumen hoch für den konkreten Testfall ;)
Hallo
Wie lasse ich mein Licht zu einer bestimmten Zeit mit einer von mir definierten Farbe
langsam hochdimmen
Beim hochdimmen soll zusätzlich die Farbe wechseln. Bei 60
Prozent leuchkraft soll Schluß sein.
set lampe_wz dimup 60 300 scheint nicht zu funktionieren
Zusätlich habe ich diese Fehlermelung
unknown attribute lightSceneParamsToSave hsv
Zitat von: elfrinjo am 15 März 2015, 22:42:40queue bug
Behoben, siehe Anhang.
Zitat von: andre07 am 16 März 2015, 20:43:36Wie lasse ich mein Licht zu einer bestimmten Zeit mit einer von mir definierten Farbe langsam hochdimmen. Beim hochdimmen soll zusätzlich die Farbe wechseln.
Mittels HSV.
set lampe_wz hsv 360,100,4 Startposition 4% (minimale) Helligkeit, Rot
set lampe_wz hsv 240,100,60 300 Endposition 60% Helligkeit, Blau (nach 300s)
Zitat von: Markus M. am 16 März 2015, 21:13:20
Behoben, siehe Anhang.
Funktioniert! Herzlichen Dank!
Also um von rot auf blau zu wechseln diese beiden Befehle
360 100 wäre dann rot und 240,100 blau
Mit einem Befehl geht das nicht ?
hsv woher weiss ich den Wert für weiss oder pink
kann man das irgendwie nachschlagen
sorry ist meine erste Lampe mit diesem Feature
Zitat von: andre07 am 16 März 2015, 22:06:45
Also um von rot auf blau zu wechseln diese beiden Befehle
360 100 wäre dann rot und 240,100 blau
Mit einem Befehl geht das nicht ?
hsv woher weiss ich den Wert für weiss oder pink
kann man das irgendwie nachschlagen
sorry ist meine erste Lampe mit diesem Feature
ad 1: Ein Kommando gibt der Lampe die Zielfarbe und den Zeitraum in dem dorthin gewechselt wird (plus zwei Optionen).
Wenn du von Rot nach Blau willst, musst du also zuerst Rot schalten und dann das Kommando geben binnen n Sekunden nach Blau zu wechseln.
ad 2: Hier eine Erklärung zum HSV Farbraum: http://de.wikipedia.org/wiki/HSV-Farbraum
Und hier eine Website auf der du die Werte testen kannst: http://colorizer.org/
Es spricht übrigens auch nichts (zumindest nicht viel) dagegen klassische RGB Werte zu nutzen. Der Color Picker dafür ist sogar schon in FHEM eingebaut.
Matt, please replace the SVN version with my latest upload.
If you have any questions about the code changes, I'll be happy to explain.
Markus
Moin,
könnt ihr mir einen Tipp geben, wie ich einen RGB Colorpicker als WebCmd setze der den aktuellen Farbwert des Milight auch dann anzeigt wenn er von anderer Stelle gesetzt wird?
Ich (glaube) dass ich zur Zeit darüber stolpere, dass Reading und Set für RGB unterschiedlich geschrieben werden (rgb vs. RGB)
Cheers, Jörg
Zitat von: elfrinjo am 22 März 2015, 18:35:53Ich (glaube) dass ich zur Zeit darüber stolpere, dass Reading und Set für RGB unterschiedlich geschrieben werden (rgb vs. RGB)
Was so natürlich keinen Sinn macht.
Fix siehe Anhang, die alten Reading bekommst du raus mit
deletereading lampe.* RGB (je nachdem wie deine Geräte heissen).
Danke, funktioniert!
Warum funktioniert dieses DOIF nicht
([?{sunset(0,"19:00","21:00")}-23:00] and [HausBewohner] eq "home" ) (set Wz.DeckeFarbe hsv 0,0,75 300) DOELSE (set Wz.DeckeFarbe dim 0 120)
Fhem meldet mir diesen Fehler
set Wz.DeckeFarbe hsv 0: Usage: set Wz.DeckeFarbe hsv <h(0..360)>,<s(0..100)>,<v(0..100)> [seconds(0..x)] [flags(l=long path|q=don't clear queue)] 75 300: Unknown command 75, try help.
Wenn ich aber set Wz.DeckeFarbe hsv 0,0,75 300 händisch eingebe funktioniert es
cu
http://fhem.de/commandref_DE.html#DOIF
ZitatFalls ein Komma nicht als Trennzeichen zwischen FHEM-Befehlen gelten soll, so muss der FHEM-Ausdruck zusätzlich in runde Klammern gesetzt werden:
;)
So dann ((set lampe hsv 0,0,75 300)) ?? :-\
So funktioniert es nur leider dimmt er so nicht langsam hoch
([?{sunset(0,"19:00","21:00")}-23:00] and [HausBewohner] eq "home" ) ((set Wz.DeckeFarbe hsv 0,0,75 300)) DOELSE (set Wz.DeckeFarbe dim 0 120)
Wenn ich es dann so versuche bekomme ich error im log
([?{sunset(0,"19:00","21:00")}-23:00] and [HausBewohner] eq "home" ) ((set Wz.DeckeFarbe dim 0,set Wz.DeckeFarbe hsv 0,0,75 300)) DOELSE (set Wz.DeckeFarbe dim 0 120)
Vieleicht bin ich auch hier im falschen Thread um meine Fragen loszuwerden
Hi,
bin selbst noch neu im Thema aber:
dim <percent(0..100)> [seconds(0..x)] [flags(l=long path|q=don't clear queue)]
heißt für mich:
(set Wz.DeckeFarbe dim 0 120) <-- die 0 muss z.B. 100 sein für 100%.
Gruß
Torsten
Wie sieht es mit dem Modul eigentlich bei der Zuverlässigkeit aus? Hab momentan noch mehrere LD382 im Einsatz, die ja direkt über Wifi mit Fhem kommunizieren. Leider gibt das immer wieder Probleme, so das manchmal die LEDs erst nach mehreren Aufforderungen reagieren oder der Controller erst neu gestartet werden muss. Gibt es solche Probleme auch mit den MiLights oder hilft da die zusätzliche Funkverbindung?
Was ich hier schon mehrmals gefragt habe, aber immer noch nicht beantwortet bekommen habe: Sind Dimmvorgänge und Farbverläufe komplett ruckelfrei? Ist der Controller selbst dafür verantwortlich oder muss das vorher in Fhem berechnet und in einzelnen Befehlen übertragen werden?
Zitat von: kennymc.c am 29 März 2015, 01:15:41
Wie sieht es mit dem Modul eigentlich bei der Zuverlässigkeit aus? Hab momentan noch mehrere LD382 im Einsatz, die ja direkt über Wifi mit Fhem kommunizieren. Leider gibt das immer wieder Probleme, so das manchmal die LEDs erst nach mehreren Aufforderungen reagieren oder der Controller erst neu gestartet werden muss. Gibt es solche Probleme auch mit den MiLights oder hilft da die zusätzliche Funkverbindung?
Was ich hier schon mehrmals gefragt habe, aber immer noch nicht beantwortet bekommen habe: Sind Dimmvorgänge und Farbverläufe komplett ruckelfrei? Ist der Controller selbst dafür verantwortlich oder muss das vorher in Fhem berechnet und in einzelnen Befehlen übertragen werden?
Ich habe momentan eine LED Stripe und 4 Lampen von Milight über fhem im Einsatz.
Zuverlässigkeit: 100% :) nichts mit Neustarten oder so...
Dimmvorgänge sind ruckelfrein (gerade noch getestet und von Frau bestätigt)
Zitat von: kennymc.c am 29 März 2015, 01:15:41Sind Dimmvorgänge und Farbverläufe komplett ruckelfrei? Ist der Controller selbst dafür verantwortlich oder muss das vorher in Fhem berechnet und in einzelnen Befehlen übertragen werden?
Die Befehle (Queue) laufen in FHEM.
Übertragungsfehler sind selten, kommen aber vor.
Ich hatte ein Montagsmodell der Bridge das ständig die wlan Verbindung verloren hat. Wenn die hält, bemerkt man im Alltag aber nichts. Wenn nicht, nimmt das Modul in meiner Version den Schaltvorgang nicht an.
Eventuell kann ich das noch umbauen so dass die Befehle in die Queue geschrieben werden.
Ich weiß aber nicht ob es Sinn macht, etwas 10 oder 30 Minuten später auszuführen wenn die Verbindung wieder da ist.
Für White habe ich einen Modus eingebaut der so etwas teilweise tut.
Bei absoluten Befehlen (nur RGBW) könnte man auch mehrmals senden.
Ohne dass das jemand wirklich braucht werde ich es aber nicht implementieren. Das kann man nach Bedarf auch in der Programmierung machen.
Bei mir läuft es jedenfalls zuverlässig genug.
Gruß, Markus
Hallo,
habe dieses Modul jetzt seit Anfang des Jahres im Einsatz, vorher das Wifilight.pm von hermannJ.
Bin total zufrieden nur habe ich ein kleines Problem.
Immer mal wieder schleicht sich dieses Stück Code ein, obwohl ich nichts daran verändere, auch nach einem Löschen ist es nach ein paar Tagen wieder da und gibt natürlich eine Fehlermeldung, aber woher kommt dieses:
attr LICHT lightSceneParamsToSave hsv
Zitat von: hyper2910 am 04 April 2015, 11:10:35Immer mal wieder schleicht sich dieses Stück Code ein, obwohl ich nichts daran verändere, auch nach einem Löschen ist es nach ein paar Tagen wieder da und gibt natürlich eine Fehlermeldung, aber woher kommt dieses:
attr LICHT lightSceneParamsToSave hsv
Das Attribut ist eigentlich von Lightscene, wird aber in MilightDevice gesetzt. Ist ein wenig unglücklich gemacht.
Nimm einfach meine Version von weiter oben (http://forum.fhem.de/index.php?action=dlattach;topic=30638.0;attach=29761), dann sollte der Fehler weg sein und das Attribut nicht weiter stören.
Neue Version, neues Glück!
Heute mit dabei: gamma zur Helligkeitskorrektur.
Funktioniert so wie bei WifiLight nur andersrum, da dort die Werte verdreht waren.
Hoher Wert = dunkler, kleiner Wert = heller.
Der dim Slider wird dabei auf 1er Schritte gesetzt, da die Steps bei einer Korrektur nicht mehr linear sind.
Die Version erfordert einen Neustart von FHEM.
Neue Version, neues Glück!
Heute mit dabei: gamma zur Helligkeitskorrektur.
Funktioniert so wie bei WifiLight nur andersrum, da dort die Werte verdreht waren.
Hoher Wert = dunkler, kleiner Wert = heller.
Der dim Slider wird dabei auf 1er Schritte gesetzt, da die Steps bei einer Korrektur nicht mehr linear sind.
Die Bridge hat ein checkInterval bekommen, falls jemand nicht alle 10 Sekunden einen Ping rausschicken will.
Die Version erfordert einen Neustart von FHEM.
Hallo Markus,
irgendwas ist da noch, nach Neustart kommt:
Prototype mismatch: sub main::round ($$) vs none at /usr/share/perl/5.14/Exporter.pm line 67, <$fh> line 1875.
at ./FHEM/31_MilightDevice.pm line 34
Zitat von: det. am 05 April 2015, 20:43:20
Hallo Markus,
irgendwas ist da noch, nach Neustart kommt:
Prototype mismatch: sub main::round ($$) vs none at /usr/share/perl/5.14/Exporter.pm line 67, <$fh> line 1875.
at ./FHEM/31_MilightDevice.pm line 34
In der Zeile steht "
use Math::Round;", könnte also an deiner Perl Installation liegen.
Da müsstest du mal jemanden fragen der sich damit auskennt ;)
habe den gleichen fehler:
Prototype mismatch: sub main::round ($$) vs none at /usr/share/perl/5.14/Exporter.pm line 67, <> line 6.
at ./FHEM/31_MilightDevice.pm line 34
Zitat von: Markus M. am 05 April 2015, 22:02:10
In der Zeile steht "use Math::Round;", könnte also an deiner Perl Installation liegen.
Da müsstest du mal jemanden fragen der sich damit auskennt ;)
Da fehlt das entsprechende Perl-Paket. Auf Debian-basierten Systemen genügt `apt-get install libmath-round-perl`. Auf anderen Systemen gibt es evtl. Entsprechungen dazu. Zur Not: `perl -MCPAN -e shell
` und `install Math::Round`
Sorry,
Das Perl Paket hatte ich geprüft. War schon immer installiert. Nach Rückspielen der vorgänger Version des Moduls ist der Fehler weg. Ist also alles ok, läuft prima und macht was es soll.
Jetzt bin ich etwas verwirrt.
Welche Version läuft, welche nicht?
an dem Perl Paket liegt es nicht:
root@cubie:~# apt-get install libmath-round-perl
Reading package lists... Done
Building dependency tree
Reading state information... Done
libmath-round-perl is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Wenn die Module Release Nummern hätten wäre das einfach zu beantworten. Die lauffähige Version auf meinem System ist vom 27.2.2015
Nach einem kompletten Neustart des cubie ist der Fehler weg.
Zitat von: det. am 07 April 2015, 18:31:38Die lauffähige Version auf meinem System ist vom 27.2.2015
Releasenummern bzw. das Datum werde ich in zukünftigen Änderungen eintragen.
Wenn mein letzter Upload bei dir nicht läuft, vermute ich das Problem aber trotzdem in deiner Installation.
Schick mir Log (verbose 5) und Definition doch bitte mal per PM.
Hallo
Das Modul läuft bei mir mittlerweile sehr gut danke
Eine Frage hätte ich noch wie kann man das ganze
in einem loop Schleife laufen lassen.
Habe mir dazu einen dummy mit notify geschrieben
define startlicht dummy
define farbverlauf notify startlicht
define farbloop notify startlicht:on set Wz.DeckeFarbe hsv 240,100,0 ;set Wz.DeckeFarbe hsv 60,100,100
q
aber wie muß ich das ändern damit es in einer Schleife läuft
cu
Zitat von: inesa394 am 11 April 2015, 13:53:53
wie muß ich das ändern damit es in einer Schleife läuft
Ein
at das bei Queue-Länge n alle n*2 Minuten startet und den ersten Befehl ohne 'q' aufruft, vielleicht?
heute ist die Fehlermeldung wieder da:
Prototype mismatch: sub main::round ($$) vs none at /usr/share/perl/5.14/Exporter.pm line 67, <> line 7.
at ./FHEM/31_MilightDevice.pm line 34
Aber wie packe ich qeue länge n*2 in ein at oder habe ich da was falsch verstanden
define farbloop at +*00:02:00 set Wz.DeckeFarbe hsv 240,100,0 ;set Wz.DeckeFarbe hsv 60,100,100 q
so denke ich nicht geht es nicht
@mattwire & Markus M.
It seems not all of Markus' updates made it to SVN, yet. Maybe you want to add them :)
Cheers, Jörg
EDIT: And it seems that the new updater wants to "correct" all out-of-band packages; so it would be really nice in to have the fixes in SVN.
Moin,
ich hab die Version vom 5.April http://forum.fhem.de/index.php/topic,30638.msg282274.html#msg282274 (http://forum.fhem.de/index.php/topic,30638.msg282274.html#msg282274) im Einsatz.
Hier sehe ich im Log folgenden Fehler, hat aber wohl weiter keine Auswirkungen:
2015.05.04 15:41:49 1: PERL WARNING: Use of uninitialized value $cv in concatenation (.) or string at ./FHEM/31_MilightDevice.pm line 1071.
PS: Ich bin für die Einführung von Versionsnummern in den Modulen...
Gruß
effe
Version am 5. April sind heute im SVN. Danke MarkusM fuer alles Ihres Arbeit mit dem Modul!
Matthew
Hallo,
möchte mich auch für das tolle modul bedanken und habe auch gleich noch eine Frage...
Habt ihr auch das Phänomen:
Bulbs, Stripes aus --> Strom weg --> Strom wieder da --> Lampen an :-[
Grüße Dirk
Zitat von: gibacht am 06 Mai 2015, 15:12:31
Hallo,
möchte mich auch für das tolle modul bedanken und habe auch gleich noch eine Frage...
Habt ihr auch das Phänomen:
Bulbs, Stripes aus --> Strom weg --> Strom wieder da --> Lampen an :-[
Grüße Dirk
Ja, bei meinen Bulbs ebenfalls. Von der Helligkeit entspricht das etwa dem Night Mode.
ohweia, das ist echt ungünstig. Es ändert sich der Status, den unser FHEM nicht mitbekommt.
Bin noch auf der Suche nach einer Lösung...
Wenn einer was weiß... lasst mich bitte nicht vergebens suchen...
Wenn ich es richtig verstehe ist das seitens der Milights so gewollt.
Nachdem der Strom weg war geht die Bulb in den letzten eingeschalteten Zustand.
Durch das Abschalten mit Dim-Down durch dieses Modul ist das ein dunkles Weiß.
Das Verhalten ist sogar durchaus sinnvoll!
Hängt die Lampe an einem Wandschalter, und wird nicht (nur) durch FHEM, RC oder die App geschaltet, kann man sie trotzdem wie eine "normale" Lampe nutzen.
Dann stimmt bei mir was nicht. Egal mit welcher Option ich ausschalte (z.B. auch set 'device' off), wenn ich den Strom wieder einschalte leuchten sie...
Woran könnte das liegen, bzw. was mache ich falsch?
Dann habe ich mich missverständlich ausgedrückt:
Wenn der Strom wiederkommt soll die Lampe leuchten.
Hintergrund der Philosophie: Stromschalter vor Fernbedienung.
Lampe am Wandschalter abschalten -> Lampe aus (wie auch nicht)
Lampe am Wandschalter anschalten -> Lampe an.
Noch eine Kleinigkeit zum Modul:
"set dim" steuert das Reading "brightness"
Das sollte doch wahrscheinlich auch einheitlich sein, oder?
Cheers, Jörg
Gute Frage. Wie ist es bei anderen Modulen?
Hi,
bei mir "brightness" - damit auch bei "Euch" :) Macht mMn auch Sinn (HSV) hat aber den Nachteil das die fhemweb slider nur per userReading funktionieren. Man könnte "brightness" auf "dim" doppeln.
Bin mir aber da noch unsicher weil es reduntant wäre (eigentlich unschön) und nur dem slider was bringt.
vg
jörg
Ich hatte das Problem das mein state der Briddge immer "unreachable" war. Ich Code habe ich gesehen, das dies per UDP Ping getestet wird:
my $p = Net::Ping->new('udp');
In den perldocs hab ich folgendes zum pingen per UDP gefunden:
Zitat
It should be borne in mind that, for a udp ping, a host will be reported as unreachable if it is not running the appropriate echo service. For Unix-like systems see inetd(8) for more information.
Ich weiß jetzt nicht ob es ein generelles Problem ist oder ob sich meine V3 Bridge anders verhält als andere, aber generell sollte es ein TCP Ping auch tun.
my $p = Net::Ping->new('tcp');
Damit erhalte ich einen korrekten state Wert.
Hmm, mit der App klappt es während unreachable dasteht?
Ich bau dir bei Gelegenheit mal ein Attribut für TCP Pings ein.
Edit: Ist im Anhang, Attribut tcpPing
Hallo,
habe nach meinem letzten FHEM-Update das Problem, dass FHEM komplett abschmiert, sobald ich ein Milight device anspreche.
Ich habe das Problem http://forum.fhem.de/index.php/topic,37514.0.html (http://forum.fhem.de/index.php/topic,37514.0.html)schon mal beschrieben, aber noch keine Lösung gefunden.
Evtl jmd ähnliche Probleme, oder besser noch nen Lösungsansatz?
VG,
Tim
kann ich bestätigen. Lösung ( vorübergehend) die 2 Device gelöscht. Da die IPHONE App prima geht, stelle ich die Farben übergangsweise damit ein.
sorry für die doofe frage, aber wäre es dann möglich, dass der fehler durch das letzte update verursacht wurde?
wie wird denn in der regel bei solchen problemen verfahren?
uni(n)formierte grüße,
Tim
Zitat von: zauberfee am 02 Juni 2015, 17:44:46
sorry für die doofe frage, aber wäre es dann möglich, dass der fehler durch das letzte update verursacht wurde?
Ja, unter Umständen kann es sein dass das Fehler sind die nur in Setups auftreten auf die leider keiner getestet hat.
Zitatwie wird denn in der regel bei solchen problemen verfahren?
Ihr wartet bis ich aus dem Urlaub zurück bin und testet die neue Version ;)
Bitte die Ausgabe von
list <device> ehe es abschmiert auch posten und FHEM manuell starten um zu sehen woran es letzendlich scheitert.
Bisher habe ich in den Logs leider nur Warnungen gesehen, keine Absturzursache.
Probiert mal die Version im Anhang und gebt Bescheid.
M
hallo, ich hoffe ich bin hier richtig?
ich versuche drei set befehle innerhalb eines dois abzusetzen.
es wäre schön wenn ihr mal über den code schauen könntet um mir einen tipp zu geben.
Internals:
DEF (([tt] < 100) and
([tt] > 0))
(set buro hue 40,set buro dim 100 300,set buro hue 260 12000 l)
DOELSEIF
(([tt] == 0) or
([tt] == 100))
(set buro dim 0 600)
NAME katzenlicht
NR 69
NTFY_ORDER 50-katzenlicht
STATE initialized
TYPE DOIF
Readings:
2015-06-05 12:24:59 state initialized
Condition:
0 (InternalDoIf('tt','STATE','') < 100) and (InternalDoIf('tt','STATE','') > 0)
1 (InternalDoIf('tt','STATE','') == 0) or (InternalDoIf('tt','STATE','') == 100)
Devices:
0 tt
1 tt
all tt
Do:
0 set buro hue 40,set buro dim 100 300,set buro hue 260 12000 l
1 set buro dim 0 600
Helper:
last_timer 0
sleeptimer -1
Internals:
0 tt:STATE
1 tt:STATE
all tt:STATE
Itimer:
State:
Timerfunc:
Attributes:
room Doif
der do bereich:
(set buro hue 40,set buro dim 100 300,set buro hue 260 12000 l)
milight
wird nicht richtig ausgeführt. es wird ein step in
set buro dim 100 300
ausgeführt und dann bleibt alles stehn.
jeder einzelne set befehl für sich allein läuft.
Zitat von: 3dmanipulator am 06 Juni 2015, 11:02:50(set buro hue 40,set buro dim 100 300,set buro hue 260 12000 l)
wird nicht richtig ausgeführt. es wird ein step in
set buro dim 100 300
ausgeführt und dann bleibt alles stehn.
jeder einzelne set befehl für sich allein läuft.
Ich bin mir relativ sicher dass deine Transition nach 260 danach noch läuft, allerdings mit der Helligkeit von vorher +1.
Du hast das
q wie Queue vergessen, dein mittlerer Befehl wird sofort wieder überschrieben.
(set buro hue 40,set buro dim 100 300 q,set buro hue 260 12000 lq)Sonst irgendwelche Probleme mit der letzten Version?
Markus
hallo markus,
danke für die lösung, das mit dem q habe ich vollkommen überlesen, bzw. nicht richtig bei mir eingeordnet.
ansonsten habe ich keine größeren probleme mit dem milight modul (abstürze und so).
aber noch 2 fragen:
bei den zeitangaben muss ich immer den doppelten sec wert eingeben (100 für 50 sec etc)
beim dimmen verändert sicht die helligkeit bei mir nur in deutlichen helligkeitsschritten ruckartig, und während eines durchgangs auch mit sich andauernd verändernder geschwindigkeit. ..und der dim schritt zu "0" ist deutlich zu sehen.
liegt das an den milight birnen oder kann ich da noch was verbessern (mit dem handsender lassen sich manuell weichere übergänge darstellen).
danke horst
Hi Markus,
danke schon einmal.
Ich war das Wochenende weg und ab morgen bin ich ne Woche im Urlaub.
Dann geht es weiter...
Gruß,
Tim
Hallo,
es wäre mal angebracht sich um die Fehlermeldungen zu kümmern.
Es hat wohl keine Auswirkungen auf die Funktion aber es sieht unschön aus im Logfile.
Zitat2015.06.13 10:04:54 1: PERL WARNING: Use of uninitialized value $cv in concatenation (.) or string at ./FHEM/31_MilightDevice.pm line 1071.
2015.06.13 10:04:54 1: PERL WARNING: Use of uninitialized value $cv in chr at ./FHEM/31_MilightDevice.pm line 1101.
2015.06.13 10:04:54 1: PERL WARNING: Use of uninitialized value $cv in chr at ./FHEM/31_MilightDevice.pm line 1105.
Auch mein Raspberry bringt den Fehler:
ZitatPrototype mismatch: sub main::round ($$) vs none at /usr/share/perl/5.14/Exporter.pm line 67, <$fh> line 1821.
at ./FHEM/31_MilightDevice.pm line 34
Auf Dauer ist das echt nervig.
Gruß
Tom
Zitat von: Tom111 am 13 Juni 2015, 10:23:32
Hallo,
es wäre mal angebracht sich um die Fehlermeldungen zu kümmern.
Es hat wohl keine Auswirkungen auf die Funktion aber es sieht unschön aus im Logfile.
Dein erster Fehler verrät dir, dass mit deiner Farbkorrektur etwas nicht stimmt bzw. sie keine internen Werte hat.
Der zweite... ich bin kein Perl Coder. Ich habe manchmal keine Ahnung was Perl von mir will.
Deshalb darfst du jetzt das Versuchskaninchen spielen: In der Version im Anhang sollten die Fehler weg sein.
So, hab mich mal als Versuchskaninchen geopfert.
Die neue Datei läuft bis jetzt fehlerfrei ohne Perlwarnung, habe noch alles ausprobiert und es funktioniert.
Zitat von: Markus M. am 13 Juni 2015, 13:00:35
Dein erster Fehler verrät dir, dass mit deiner Farbkorrektur etwas nicht stimmt bzw. sie keine internen Werte hat.
Sorry, aber mit dieser Aussage kann ich leider nichts anfangen, was für eine Farbkorrektur, wo muss ich nachsehen um was einzustellen !?
Danke nochmals für das Update.
Gruß
Tom
Neue Version zum Testen, die ganz ohne Math::Round auskommen sollte
Hallo Markus,
hab die neue Version geladen und läuft.
Aber es kommt immer noch :
Zitat2015.06.14 20:38:22 1: PERL WARNING: Use of uninitialized value $cv in concatenation (.) or string at ./FHEM/31_MilightDevice.pm line 1076.
2015.06.14 20:38:22 1: PERL WARNING: Use of uninitialized value $cv in chr at ./FHEM/31_MilightDevice.pm line 1106.
2015.06.14 20:38:22 1: PERL WARNING: Use of uninitialized value $cv in chr at ./FHEM/31_MilightDevice.pm line 1110.
Zitat von: Tom111 am 14 Juni 2015, 20:42:16
Hallo Markus,
hab die neue Version geladen und läuft.
Aber es kommt immer noch ...
Irgendwas stimmt bei dir nicht mit der internen Farbkorrektur.
list
milightdevice (Ergebnis bitte mal hier posten)
Danach: attr
milightdevice colorCast 0,0,0,0,0,0 und gucken was dann passiert.
Hallo Markus,
Fehler scheint behoben, ich habe wohl vergessen
attr milightdevice colorCast 0,0,0,0,0,0einzutragen. Jetzt wird der Fehler nicht mehr angezeigt.
Übrigens hast du die Datei aus deiner Antwort #156 noch nicht hochgeladen mit der alten Version "31_MilightDevice.pm" bekomme
ich auf den Raspberry immer die Fehlermeldung:
ZitatPrototype mismatch: sub main::round ($$) vs none at /usr/share/perl/5.14/Exporter.pm line 67, <$fh> line 1821.
at ./FHEM/31_MilightDevice.pm line 34
Danke für deine Hilfe !
Gruß
Tom
????
Zitat von: Tom111 am 15 Juni 2015, 08:58:55
Übrigens hast du die Datei aus deiner Antwort #156 noch nicht hochgeladen mit der alten Version "31_MilightDevice.pm" bekomme
ich auf den Raspberry immer die Fehlermeldung:
Danke für deine Hilfe !
Gruß
Tom
Mit welcher Version?
Die letzte die ich hochgeladen habe braucht überhaupt kein Math::Round mehr.
Nochmal Hallo,
diese Version erzeugt den Fehler nicht:
http://forum.fhem.de/index.php?action=dlattach;topic=30638.0;attach=33418
Die Version, die mir täglich bei den Updates angeboten wird, habe ich bis jetzt deshalb immer wieder durch die
o.g. Version überschreiben müssen.
Gruß
Tom
Ja, wenn die Änderungen niemand ins SVN eincheckt ist das klar.
Ich bin leider nicht als FHEM Entwickler registriert.
Hallo,
Habs Gestern eingecheckt :-)
Wunderbar, kann ich endlich "exclude_from_update" wieder entfernen :D
Zitat von: mattwire am 26 Juni 2015, 22:11:08
Hallo,
Habs Gestern eingecheckt :-)
Danke!
Kannst du noch ein Update der Bridge machen, für alle die TCP Pings wollen?
http://forum.fhem.de/index.php/topic,30638.msg296976.html#msg296976 (http://forum.fhem.de/index.php/topic,30638.msg296976.html#msg296976)
ZitatKannst du noch ein Update der Bridge machen, für alle die TCP Pings wollen?
Ja, ich habe ein Kleine Änderung gemacht bei der "ping" code. Könntest du bei der neueste Version auf SVN modifizieren mit die TCP ping attribut?
Hallo,
ich habe ein merkwürdiges Verhalten und hab den Verdacht, daß das vom milight-Modul kommt. Vielleicht kennt das ja jemand? (Suche habe ich erfolglos versucht).
Wie hier http://forum.fhem.de/index.php/topic,39263.0.html (http://forum.fhem.de/index.php/topic,39263.0.html) beschrieben, habe ich einen Arduino mit firmata in Betrieb genommen und unter anderem einen Taster angeschlossen.
Nun ist mir aufgefallen, daß ich bei Betätigung des Tasters folgende Meldung im log bekomme:
2015.07.18 22:25:56 5: wzmilight_Notify: Triggered by zirkulation_direkttaster; reading: on
Nur habe ich kein wzmilight_Notify definiert und auch den String nicht in den fhem-Verzeichnissen gefunden?!
Definition der milight-Bridge:
define wzmilight MilightBridge 192.168.1.187
attr wzmilight checkInterval 10
attr wzmilight event-on-change-reading state
attr wzmilight port 8899
attr wzmilight room wz
attr wzmilight sendInterval 100
Kennt jemand dieses Verhalten und kann mir weiterhelfen? Wäre toll...
Danke und cheers,
Pula
Hallo zusammen,
ich habe immer noch Probleme mit dem Milight-Modul. Habe es jetzt nach einiger Zeit wieder damit versucht, aber FHEM stürzt immer wieder ab. Im Log steht:
Zitat
PERL WARNING: Use of uninitialized value $cv in concatenation (.) or string at ./FHEM/31_MilightDevice.pm line 1076
Momentan bin ich wieder auf Wifilight umgestiegen.
Hat jemand vielleicht einen Rat oder einen Tip?
Vielen Dank
Gruß Thommy
attr milightdevice colorCast 0,0,0,0,0,0
Im Zweifelsfall mal das Device neu anlegen.
Ich habe leider keine Ahnung warum das passiert, der Defaultwert sollte beim Init verwendet werden.
Zitat von: mattwire am 30 Juni 2015, 11:56:46
Ja, ich habe ein Kleine Änderung gemacht bei der "ping" code. Könntest du bei der neueste Version auf SVN modifizieren mit die TCP ping attribut?
Sorry, hatte ich vergessen.
Habs eingecheckt.
Hi ich habe 2 Fragen könnt ihr mir helfen wie der Blink befehl funktioniert bzw. ist da mit so etwas wie ein Blinken umsetzbar?
Und der restorePreviousState berücksichtigt bei mir an/aus sowie brightness nicht ist das so gewollt?
greets
Blinken kannst du über mehrmals Mode probieren. Damit den aktuellen Status synchron zu halten wird aber schwierig.
Was meinst du mit der zweiten Frage?
Was tut es aktuell und was würdest du erwarten?
Ich nutze die Funktion selbst nicht.
Ich habe einen Tür Sensor mit notifys verknüpft.
Wenn das open notify ausgelöst wird soll zb. Rotes Licht leuchten funktioniert soweit auch.
Wenn das close notify ausgelöst wird sollte das Licht wieder seinen letzten Zustand einnehmen.(ob AN oder Aus / Farbe / Dimmzustand)
Das funktionert soweit aber nicht, die Farben werden korrekt gespeichert allerdings nicht der dimmwert oder ob die Lampen an oder aus waren.
Hab ich weiss auf 0 gedimmt (also lampe aus) und ich dann die türe öffne und wieder schliesse ist weiss auf 100gedimmt.
Könnte man in den PreviousState nicht die hex farbe reinschreiben?
Ich bin mir relativ sicher dass das hier nicht aus allen Modi und zurück einwandfrei funktionieren wird,
du hast dich aber gerade freiwillig zur Fehlersuche gemeldet ;)
Mit dieser Testversion sollte on/off klappen und auch während Transitions sollte der previousState nicht mehr gesetzt werden.
Was passiert wenn man während einer Transition nochmal irgendwas mit oder ohne Queue schaltet hab ich nicht ausprobiert - das ist jetzt dein Job ;)
Hi danke für deine Hilfe und gerne...
Korrektur: Funktioniert doch sorry ich habe gestern Abend noch eine Änderung am notify vorübergehend vorgenommen und das vergessen. Jetzt tut es nach den ersten 5 tests.
Setze mich mal an die verschiedenen Modis....
Ok, bitte ein wenig testen und Bescheid geben ob das im produktiven Betrieb funktioniert.
Wenn es bis Ende nächster Woche nicht abgestürzt ist, checke ich den Code ein.
Es scheint als ob du der einzige warst, der das Feature benutzt hat - ich kann meine Türklingel, das Telefon und den Briefkasten mittlerweile aber auch in allen Räumen sehen :)
Servus zusammen,
ich habe mal eine Frage - meine Bridge ist alle paar Minuten "unreachable". Dachte das ist ein defekt und habe mir eine zweite gekauft.
Hier habe ich genau das gleiche. Habt ihr das auch?
Ich hatte das Problem mal mit einer Bridge, da hat ein Austausch aber geholfen.
Schon mal versucht, den Standort zu wechseln?
Was sagt das Router Log?
Hallo Scubao,
ich habe vor wenigen Tagen testweise die Module reaktiviert, nachdem ich diese vor einigen Monaten bereits laufen hatte. Ich hatte sie aber wieder deaktiviert, da sie Abstürze verursacht hatten. Beim erneuten Versuch bekam ich nun von Anfang an ein 'unreachable', weswegen ich den Versuch abgebrochen habe. Die Bridge ist unter der verwendeten IP-Adresse pingbar und ich nutze sie mit dem Modul WifiLight seit Monaten ohne Probleme. WifiLight hatte ich während des Tests deaktiviert, FHEM war aktuell.
Grüße,
Seli
Versuch mal auf TCP Ping umzustellen, evtl. liegt es an deinem Netzwerk.
Das Modul hat aktuell keine Probleme.
Sicher dass alles richtig konfiguriert ist?
Die Abstürze kamen von der verlorenen Verbindung, das ist mittlerweile behoben.
Also kurze Rückmeldung läuft bei mir soweit, vielen Dank.
Anmerkung: Wäre es noch möglich queues aus dem restorePreviousState auszuschliessen? Also das er sich quasi den letzten zustand vor einer queue merkt?
Zitat von: speex am 19 September 2015, 20:56:44
Also kurze Rückmeldung läuft bei mir soweit, vielen Dank.
Anmerkung: Wäre es noch möglich queues aus dem restorePreviousState auszuschliessen? Also das er sich quasi den letzten zustand vor einer queue merkt?
Das sollte bereits passieren.
Möchtest du Befehle die du in einer Queue sendest komplett ignorieren?
Dann versuch mal "pq" statt nur "q".
Off Topic.
Falls noch jemand probleme hat mit dem Milight WIFI , dass es regelmässig die Wireless Verbindung verliert, hier ist ne alternative :
Das Milight Modul an einen Raspberry Pi anlöten.
http://servernetworktech.com/2014/09/limitlessled-wifi-bridge-4-0-conversion-raspberry-pi/
Hab ich selber bei mir heute morgen umgebaut und funktioniert 1A.
Coole Sache. Danach müsste man den tx doch auch direkt an einen usb seriell Wandler stecken können ?
Vg Joerg
Definitiv eine der krasseren Möglichkeiten, um die Verbindungsprobleme zu lösen :)
Ich würde aber tatsächlich erst mal ins Router Log gucken ob die Verbindung hält und nachsehen ob nicht irgendwas UDP blockiert.
Zitat von: herrmannj am 21 September 2015, 21:07:58Coole Sache. Danach müsste man den tx doch auch direkt an einen usb seriell Wandler stecken können ?
Das sollte klappen. Bonuspunkte, wenn du es schaffst den bestehenden USB Anschluss zu nutzen und einen Umschalter für Wifi/USB einzubauen ;)
Wer das nutzen möchte muss sich dann allerdings selbst um die Erweiterung des Moduls kümmern oder Matt oder mir ein Testexemplar zuschicken.
M
Ich hab ein Problem , und zwar dass mein fhem abstürzt mit folgender Meldung :
2015.09.22 11:16:12.582 1: HMLAN_Parse: HMLAN1 new condition init
2015.09.22 11:16:12.676 1: HMLAN_Parse: HMLAN1 new condition ok
2015.09.22 11:27:52.003 1: 192.168.1.96:9090 reappeared (NUC)
2015.09.22 12:10:11.368 1: in SAVE
2015.09.22 12:10:11.368 1: in SAVE
2015.09.22 12:10:11.368 1: in SAVE
2015.09.22 12:10:11.368 1: in SAVE
2015.09.22 13:36:06.421 1: 192.168.1.96:9090 disconnected, waiting to reappear (NUC)
2015.09.22 13:38:15.953 1: 192.168.1.56:1000 disconnected, waiting to reappear (HMLAN1)
2015.09.22 13:38:15.954 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.09.22 13:39:18.149 1: 192.168.1.56:1000 reappeared (HMLAN1)
2015.09.22 13:39:18.150 1: HMLAN_Parse: HMLAN1 new condition init
2015.09.22 13:39:21.192 1: HMLAN_Parse: HMLAN1 new condition ok
2015.09.22 13:41:24.266 1: 192.168.1.96:9090 reappeared (NUC)
2015.09.22 15:24:57.164 1: 192.168.1.96:9090 disconnected, waiting to reappear (NUC)
<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>
[Tue Sep 22 17:14:25 2015] fhem.pl: Can't udp protocol by name at ./FHEM/30_MilightBridge.pm line 207.
reihe 207 wäre das hier : my $p = Net::Ping->new('udp');
Eine Ahnung was das sein kann ?
Zitat von: Jumbo am 22 September 2015, 17:42:28
Eine Ahnung was das sein kann ?
Nicht wirklich, ausser dass möglicherweise mit deinem Perl was nicht stimmt.
Welche Perl Version, welches Betriebssystem?
Klappt es, wenn du die Bridge auf TCP Ping umstellst?
perl Version :
perl 5, version 18, subversion 2 (v5.18.2)
Betriebssystem :
Ubuntu 14.04.1 LTS
Wie kann ich die Bridge auf TCP ping umstellen ?
Zitat von: Jumbo am 22 September 2015, 19:57:52Wie kann ich die Bridge auf TCP ping umstellen ?
attr
milightbridgedevice tcpPing 1
ok , danke , ich stell dann mal um, und pass weiter auf :-D
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: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.
Auch mit tcp stürzt FHEM mir ab. Hier ne Fehlermeldung aus der nacht.
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 ?
Zitat von: speex am 22 September 2015, 23:03:39Ola, 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.Zitat von: Jumbo am 23 September 2015, 08:02:53
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)
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!
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
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.
Zitat von: speex am 27 September 2015, 20:09:55Wenn 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
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
@roman1528: Ich auch...
Konntest du bitte Dieses Aenderung prufen?
(CHANGED: MilightDevice_Init moved from Define to Notify to prevent execution before init_done)
Zitat von: mattwire am 14 Dezember 2015, 14:35:49
@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
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
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
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
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
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? :)
SVN Update:
- Der Farbwechsel bei niedrigerer Helligkeit (http://forum.fhem.de/index.php/topic,30638.msg337518.html#msg337518) ist jetzt mit drin.
- Die Probleme mit ColorCast sollten behoben sein
- Fehler der bei langsamen Transitions zu zu kurzer Gesamtzeit geführt hat (hoffentlich) behoben
- Code Hardening durch ein paar Fallbacks
Zitat von: yogiflop am 19 Januar 2016, 20:47:04gibt es eine Möglichkeit, einen der DiscoModi direkt anzusprechen ?
Ich würde gerne für eine Alarmanlage den 6ten DiscoMode direkt ansprechen und nutzen.
Leider nicht, ich müsste ebenso 7 mal das Kommando senden - da das aber nicht state-safe ist möchte ich das nicht ins Modul packen.
Zitat von: speex am 21 Januar 2016, 17:47:18
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?
Gib $3 für einen billigen weissen Strip aus und kleb ihn daneben :)
Neue Beta Version:
- Übergänge für weisse LEDs mit "HSV" (ct,0,brightness)
- Anpassung beim Color Temperature Fader (geht jetzt wie schon immer angedacht von 3000 bis 6500)
Bitte testen ob ich irgendwas kaputt gemacht oder vergessen habe :)
Hi Matt!
I added "HSV" transitions for white LEDs and fixed the CT slider - this definitely needs a second pair of eyes before release.
Feel free to make any changes and do the commit if it's working as intended.
Markus
edit: fixed white dimming reset to ct 3000 bug
Hi, ich habe ein kleines Problem mit SmartVisu in Kombi mit Milight.
Die Readings werden nicht aktualisiert. Wenn ich über cmd den Befehl für die Farbänderung meiner RGB Birne absetzte, sehe ich sogar in FHEM die Änderung der Readings nicht. Muss die Seite manuell refreshen damit sich der RGB Reading ändert. Somit bekommt auch SmartVisu nicht mit dass sich was geändert hat. Mit dem alten Modul Wifilight geht's.
Jemand ne idee?
Zitat von: flynt am 06 Februar 2016, 21:44:28
Hi, ich habe ein kleines Problem mit SmartVisu in Kombi mit Milight.
Die Readings werden nicht aktualisiert. Wenn ich über cmd den Befehl für die Farbänderung meiner RGB Birne absetzte, sehe ich sogar in FHEM die Änderung der Readings nicht. Muss die Seite manuell refreshen damit sich der RGB Reading ändert. Somit bekommt auch SmartVisu nicht mit dass sich was geändert hat. Mit dem alten Modul Wifilight geht's.
Jemand ne idee?
Thema: longpoll
Ist es aktiviert? Welche Plattform (PC, Tablet)? Welcher Browser?
Grüße^^
fronthem/smartVisu benötigt keinen longpoll sondern arbeitet mit Websockets.
Die Beschreibung des Problem ist allerdings etwas dürftig und außerdem schmoll ich wegen
Zitatdem alten Modul Wifilight
Spaß beiseite. Die Beschreibung reicht nicht. Reload wo ? fhem, smartvisu ?
Tip: schau ob RGB events erzeugt. Und bitte fhem unbedingt neu starten. Beim "basteln" kann der RGB converter in einen Zustand gesetzt werden in dem er blockiert.
vg
joerg
Zitat von: flynt am 06 Februar 2016, 21:44:28
Hi, ich habe ein kleines Problem mit SmartVisu in Kombi mit Milight.
Die Readings werden nicht aktualisiert. Wenn ich über cmd den Befehl für die Farbänderung meiner RGB Birne absetzte, sehe ich sogar in FHEM die Änderung der Readings nicht. Muss die Seite manuell refreshen damit sich der RGB Reading ändert. Somit bekommt auch SmartVisu nicht mit dass sich was geändert hat. Mit dem alten Modul Wifilight geht's.
Jemand ne idee?
Das problem mit der Aktualisierung SmartVisu/Fhem hatte ich in der Vergangenheit auch, überprüfe mal ob bei dir in Fhem im MilightDevice das "event-on-change-reading"-Attribut mit den entsprechenden Reading werten ausgestattet ist. Als Beispiel so siehts bei mir aus:
event-on-change-reading: state,transitionInProgress,rgb,brightness,previousStateDann sollte es eigentlich funktionieren.
Hallo Leute,
ich habe heute testweise meine 5 Milight GU10 RGBW Bulbs in Betrieb genommen und diese in den 4 Zonen hinterlegt. Gerade eben habe ich alle 4 Zonen ohne Probleme in FHEM definiert. Ich kann nun die einzelnen Zonen so wie gewünscht steuern. Gibt es eine Möglichkeit, alle 4 Zonen zusammen zu steuern? Habe schon den Thread überflogen und in der CommandRef nachgeschaut, aber nichts gefunden. Falls ich etwas übersehen haben sollte, schon einmal sorry.
Gruß Timothee
@timothee
Ich habe das mit einer structure gelöst in die ich die einzelnen
Lampen gepackt habe. define Wohnen_Licht structure room Wohnen_m_Licht Wohnen_fh_Licht
attr Wohnen_Licht userattr room_map structexclude
attr Wohnen_Licht devStateIcon off:light_light .*:light_light_dim_100
attr Wohnen_Licht group Licht
attr Wohnen_Licht room Haus,Wohnzimmer
attr Wohnen_Licht webCmd on:off:dim:hue:night:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffff00
Grüße
Matze
Hallo,
feiner Thread zu einem klasse Modul!
habe noch ein kleines aber gravierendes Problem und
Habe keinen Schimmer ob das ganze ein Hard oder software
Problem ist.
Ich lasse in einem doif 2 Zonen erst auf eine Farbe dimmen
Und dann auf eine andere Farbe. Das ganze dann nach einer kurzen
Wartezeit von vorne. Funzt einwandfrei!
Das Problem ist: während des Vorgangs ist keine
Andere Zone ansteuerbar. Fhem reagiert sofort, das Licht geht real
Aber erst mit einer enormen Verzögerung an. ( teilweise 1-2 Minuten)
Ist sowas bekannt? Liegt das an der Bridge? Am Modul?
Erfahrungswerte sind willkommen!
Grüße
Matze
Zitat von: Timothee am 20 Februar 2016, 20:08:17Ich kann nun die einzelnen Zonen so wie gewünscht steuern. Gibt es eine Möglichkeit, alle 4 Zonen zusammen zu steuern?
Ja, indem du ein Gerät mit der Zone
A (statt der Nummer) definierst.
Zitat von: smoudo am 21 Februar 2016, 21:03:55Das Problem ist: während des Vorgangs ist keine
Andere Zone ansteuerbar. Fhem reagiert sofort, das Licht geht real
Aber erst mit einer enormen Verzögerung an. ( teilweise 1-2 Minuten)
Ist sowas bekannt? Liegt das an der Bridge? Am Modul?
Eventuell hat FHEM die Verbindung zur Bridge verloren?
@Markus M. Kannst du mir erklären, wie ich das definiere? Ich bin bisher nach der Anleitung von MeinTechBlog vorgegangen... Dort wurde nur die Definition mit den Nummern (1-4) erklärt. Ich kann dann aber trotzdem noch (wenn gewünscht) jede Zone einzeln steuern?
Gruß Timothee
@Markus
Wie sehe ich das die Verbindung da ist? Wird das geloggt?
Grüße
Matze
Zitat von: Timothee am 21 Februar 2016, 21:30:02
@Markus M. Kannst du mir erklären, wie ich das definiere? Ich bin bisher nach der Anleitung von MeinTechBlog vorgegangen... Dort wurde nur die Definition mit den Nummern (1-4) erklärt. Ich kann dann aber trotzdem noch (wenn gewünscht) jede Zone einzeln steuern?
Ja, du legst ein weiteres Device mit A statt 1-4 an.
define rgbw_allgroups MilightDevice RGBW milightbridge AZitat von: smoudo am 21 Februar 2016, 21:42:37Wie sehe ich das die Verbindung da ist? Wird das geloggt?
Am Status der Bridge, den kannst du auch loggen.
Ah ok
Readings: sendfail:0
State: ok
Was hat es mit sendinterval auf sich? Steht bei mir auf 100.
Grüße
Matze
Hier mal mein Code. Vielleicht hab ich auch da nen Fehler der mir die Bridge lahm legt.
define di_Blaue_Lagune DOIF ([Blaue_Lagune] eq "on") ((set Wohnen_fh_Licht hsv 155,100,100 20), (set Wohnen_m_Licht hsv 205,100,100 20), (set Wohnen_fh_Licht hsv 205,100,100 20 q), (set Wohnen_m_Licht hsv 155,100,100 20 q)) DOELSEIF ([Blaue_Lagune] eq "off") ((set Wohnen_fh_Licht off 20), (set Wohnen_m_Licht off 20))
attr di_Blaue_Lagune do always
attr di_Blaue_Lagune repeatcmd 60
Das ganze wird per dummy geschaltet
Grüße
Matze
Hallöchen ich habe ein eigenartiges problem wenn ich in fhem per colorpicker eine farbe auswähle wird die farbe mit brightness 0 gestartet? Auch die farbflächen starten mit dem dimmwert 0 und schalten sich so immer ab?
Wisst ihr wo dieser fehler herkommen kann? Die einzigen änderungen die ich vorgenommen habe sind einen neuen Sonos Lautsprecher in Fhem zu definieren und ich habe einen RGBW Controller durch einen RGB Controller ersetzt und in Fhem bzw. an der Bridge auf die selbe zone angelernt und den ursprünglichen rgbw controller einfach nur ausser betrieb genommen ohne ihn auszulernen oder irgendwelche änderungen speziell an milight_device oder bridge. Seitdem hab ich dieses eigenartige verhalten...
Moin.
RGBW ist nicht gleich RGB. Die Controller Funktionieren etwas anders...
Du musst schon dein altes RGBW-Device in ein RGB-Device ändern... Ob das Problem mit den Dimmerwerten dadurch behoben wird kann ich allerdings nicht sagen.
Grüße^^
Hallo Roman,
danke für deinen Tipp aber der controller funktioniert so wie er soll.
Abgesehen davon wenn ich ihn rein testhalber als RGB auf slot 4 definieren möchte erhalte ich stets fehler über invalide angaben und ich soll slot 0 verwenden das funktioniert ebenso nicht.
Das Dimmproblem haben auch alle anderen Lampen auch die die wirklich rgbw sind.
Meine Vermutung ist hier fhem immer wenn ich eine farbe picke wird sie mit brightness 0 gestartet, dann muss ich manuell nochmal die brightness hochdrehen dann läuft es...
Defaultbrightness bringt hier auch keinen erfolg..
Grüße SPeex
Hallo,
ich habe seit dem letzten Update (gestern), das gleiche Problem, wie speex.
Meine RGBW strips liefen mit "set DEV rgb RRGGBB" super, jetzt aber bleiben sie aus.
Nach meinem Update am 14.02. lief alles wie gehabt, nach dem Update am 23.02. lief es nicht mehr :-/
Ich nutze ein Wake-Up-Light, welches ich über meine myUtils mit RGB Werten bestücke:
sub wakeup(@) {
my @dev=@_;
my @color=("000001","000480","4F00A8","9D02B5","C2046F","D40000","E86602","FFFF54","FFFFFF");
my $i=0;
foreach (@color) { if ($i == 0)
{ fhem("set @dev on; set @dev rgb 000001; define wakeupOff at +01:02:00 set @dev off 15");}
else
{ fhem("set @dev rgb $color[$i] 90 q");}
$i++;}
}
Das läuft seit einem Jahr super zuverlässig, nur heute morgen habe ich länger geschlafen ;)
blofield
Zitat von: blofield am 24 Februar 2016, 13:15:03Nach meinem Update am 14.02. lief alles wie gehabt, nach dem Update am 23.02. lief es nicht mehr :-/
Das Problem ist nur, dass seit dem 31.01. nichts mehr am Modul geändert wurde - daran kann es also nicht liegen.
Hallo Markus,
ich habe mal versucht, die Module 30_MilightBridge.pm und 31_MilightDevice.pm aus meinem Backup vom 14.02. in /opt/fhem/FHEM zu schieben, die ja nachweislich funktioniert haben.
Leider geht es mit den alten, getesteten Modulen auch nach einem shutdown restart nicht :-/
Also sind es wohl die Module nicht, wie Du schon sagst. Ich habe an meiner Routine auch nichts geändert.
Hast Du eine Idee, wo ich suchen kann? Irgendwas hat sich ja offensichtlich geändert.
Danke.
blofield
Hi!
Auch bei mir der selbe Fehler mit den rgb-Werten.
Der RGB-Wert wird gesendet und kommt an, aber offenbar mit Helligkeit 0?????
Hängt aber nicht mit den milight-Modulen zusammen.
Ich habe es vorerst mit einem Workaround gelöst und schalte nun alles per hsv:
##### Devices von milight-Bridge-4 #####
### Ikea_Lampan Nr.9
## Bridge: milight_bridge_4
## Gruppe auf Bridge: 1
## fhem-Device: Ikea_Lampan_A9
define Ikea_Lampan_A9 MilightDevice RGBW milight_bridge_4 5
attr Ikea_Lampan_A9 userattr Alle_MiLight_Lampan Alle_MiLight_Lampan_map structexclude
attr Ikea_Lampan_A9 Alle_MiLight_Lampen structure_Rauchmelder_Alarm_Licht_anschalten
attr Ikea_Lampan_A9 IODev milight_bridge_4
attr Ikea_Lampan_A9 alias Lampan auf Schrank
attr Ikea_Lampan_A9 devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
attr Ikea_Lampan_A9 event-on-change-reading state,transitionInProgress
attr Ikea_Lampan_A9 group Mi-Light-Devices
attr Ikea_Lampan_A9 lightSceneParamsToSave hsv
attr Ikea_Lampan_A9 restoreAtStart 1
attr Ikea_Lampan_A9 room Wohnzimmer-1
attr Ikea_Lampan_A9 webCmd aus:ein:dim:hue:weiss:rot:gruen:blau:gelb
attr Ikea_Lampan_A9 cmdIcon ein:black_FS20.on aus:black_FS20.off weiss:black_white rot:black_red gruen:black_green blau:black_blue gelb:black_yellow
attr Ikea_Lampan_A9 eventMap /on:ein/off:aus/hsv 0,0,100:weiss/hsv 0,100,100:rot/hsv 120,100,100:gruen/hsv 240,100,100:blau/hsv 60,100,100:gelb/
hi,
hat noch jemand, der Milight-User die Fehlermeldungen aus diesem Thread?
http://forum.fhem.de/index.php/topic,50046.msg417911.html#msg417911 (http://forum.fhem.de/index.php/topic,50046.msg417911.html#msg417911)
Jau hier auch.
desweiteren finde ich im Log noch folgendes, was mir vorher nicht aufgefallen ist:
2016.03.01 00:00:05 4: BlockingCall (MilightBridge_DoPing): created child (25252), uses telnetForBlockingFn_1456772350 to connect back
2016.03.01 00:00:05 4: Connection accepted from telnetForBlockingFn_1456772350_127.0.0.1_38711
2016.03.01 00:00:09 4: BlockingCall (MilightBridge_DoPing): created child (25256), uses telnetForBlockingFn_1456772350 to connect back
2016.03.01 00:00:09 4: Connection accepted from telnetForBlockingFn_1456772350_127.0.0.1_38712
das ist dann alle 10sec drin.!
Beim Start von fhem bekomme ich auch die Meldungen:
Smartmatch is experimental at ./FHEM/31_MilightDevice.pm line 138.
Smartmatch is experimental at ./FHEM/31_MilightDevice.pm line 367.
Smartmatch is experimental at ./FHEM/31_MilightDevice.pm line 398.
Smartmatch is experimental at ./FHEM/31_MilightDevice.pm line 419.
Smartmatch is experimental at ./FHEM/31_MilightDevice.pm line 464.
Smartmatch is experimental at ./FHEM/31_MilightDevice.pm line 495.
Smartmatch is experimental at ./FHEM/31_MilightDevice.pm line 522.
Smartmatch is experimental at ./FHEM/31_MilightDevice.pm line 729.
2016.02.29 20:14:11.140 1: configDB: You need to restart fhem or modify to enable new protocol.
Die Meldung "BlockingCall..." habe ich allerdings nicht im Log. Die Milight-Module sollten aktuell sein:
Latest Revision: 10962
File Rev Last Change
30_MilightBridge.pm 10939 2016-02-25 22:30:46Z mattwire
31_MilightDevice.pm 10675 2016-01-31 03:11:12Z markus-m
FIXED: You need to restart fhem or modify to enable new protocol.
besten Dank! - läuft
Matt, please have a look as I didn't have much time and don't know if I fixed the problem or just the symptoms.
Did you add a default on creation and a fallback if I delete the attribute?
das ist mir jetzt erst aufgefallen, seit dem Update vom 26.03.2016 sind Unmengen der folgenden LOG-Einträge aufgelaufen:
Hier nur ein Teil der LOG-Einträge:
2016.02.26 11:00:35 1: Timeout for MilightBridge_DoPing reached, terminated process 14116
2016.02.26 11:00:35 3: BlockingCall for MiLight was aborted
2016.02.26 11:00:59 1: Timeout for MilightBridge_DoPing reached, terminated process 14148
2016.02.26 11:00:59 3: BlockingCall for MiLight was aborted
2016.02.26 11:01:11 1: Timeout for MilightBridge_DoPing reached, terminated process 14176
2016.02.26 11:01:11 3: BlockingCall for MiLight was aborted
2016.02.26 11:01:23 1: Timeout for MilightBridge_DoPing reached, terminated process 14186
2016.02.26 11:01:23 3: BlockingCall for MiLight was aborted
2016.02.26 11:01:35 1: Timeout for MilightBridge_DoPing reached, terminated process 14192
2016.02.26 11:01:35 3: BlockingCall for MiLight was aborted
2016.02.26 11:01:59 1: Timeout for MilightBridge_DoPing reached, terminated process 14213
2016.02.26 11:01:59 3: BlockingCall for MiLight was aborted
2016.02.26 11:02:23 1: Timeout for MilightBridge_DoPing reached, terminated process 14235
2016.02.26 11:02:23 3: BlockingCall for MiLight was aborted
2016.02.26 11:02:35 1: Timeout for MilightBridge_DoPing reached, terminated process 14242
2016.02.26 11:02:35 3: BlockingCall for MiLight was aborted
2016.02.26 11:02:47 1: Timeout for MilightBridge_DoPing reached, terminated process 14248
2016.02.26 11:02:47 3: BlockingCall for MiLight was aborted
2016.02.26 11:02:59 1: Timeout for MilightBridge_DoPing reached, terminated process 14276
2016.02.26 11:02:59 3: BlockingCall for MiLight was aborted
2016.02.26 11:03:23 1: Timeout for MilightBridge_DoPing reached, terminated process 14294
2016.02.26 11:03:23 3: BlockingCall for MiLight was aborted
2016.02.26 11:03:35 1: Timeout for MilightBridge_DoPing reached, terminated process 14305
2016.02.26 11:03:35 3: BlockingCall for MiLight was aborted
Die Einträge kommen immer dann wenn die Bridge abgeschaltet wird. (das Abschalten der Bridge geschieht automatisch wenn sie nicht gebraucht wird, somit verringern sich die Energiekosten).
Ich habe eine Version der 30_MilightBridge.pm von einer Sicherungskopie vom 19.02. wieder zurück gespielt und 30_MilightBridge.pm exclude_from_update gesetzt!
Ich hoffe dass der Fehler schnell behoben werden kann.
Gruß
Tom
Zitat von: Tom111 am 02 März 2016, 23:04:20
das ist mir jetzt erst aufgefallen, seit dem Update vom 26.03.2016 sind Unmengen der folgenden LOG-Einträge aufgelaufen:
...
Die Einträge kommen immer dann wenn die Bridge abgeschaltet wird. (das Abschalten der Bridge geschieht automatisch wenn sie nicht gebraucht wird, somit verringern sich die Energiekosten).
Ich habe eine Version der 30_MilightBridge.pm von einer Sicherungskopie vom 19.02. wieder zurück gespielt und 30_MilightBridge.pm exclude_from_update gesetzt!
Ich hoffe dass der Fehler schnell behoben werden kann.
Der Fehler wird nicht behoben, weil es keiner ist.
Kannst du allerdings einfach selbst beheben:
attr deineAbgeschalteteBridge disable 1Ich bezweifle übrigens ernsthaft, dass du mit dem Abschalten der Bridge Strom sparst; häng sie lieber mit an die Versorgung deines Servers.
Zitat von: Markus M. am 03 März 2016, 18:21:06
Der Fehler wird nicht behoben, weil es keiner ist.
Mit der alten Version klappt es aber ohne Fehlermeldung!
Zitat von: Markus M. am 03 März 2016, 18:21:06
Kannst du allerdings einfach selbst beheben: attr deineAbgeschalteteBridge disable 1
Ich bin mir nicht ganz sicher, krieg ich denn überhaupt noch ein Eintrag ins LOG wenn ich den Befehl so eingebe?
Zitat von: Markus M. am 03 März 2016, 18:21:06
Ich bezweifle übrigens ernsthaft, dass du mit dem Abschalten der Bridge Strom sparst; häng sie lieber mit an die Versorgung deines Servers.
Falsch!Stromkosten mit ständig durchlaufender Bridge => 4,75€/a
Stromkosten mit automatischer Abschaltung => 2,92€/a
Gespart = 1,83€ !
Zitat von: Tom111 am 03 März 2016, 20:16:32Ich bin mir nicht ganz sicher, krieg ich denn überhaupt noch ein Eintrag ins LOG wenn ich den Befehl so eingebe?
Damit deaktivierst du das FHEM Gerät, was Sinn macht während du das physische Gerät abschaltest.
ZitatStromkosten mit ständig durchlaufender Bridge => 4,75€/a
Stromkosten mit automatischer Abschaltung => 2,92€/a
Gespart = 1,83€ !
Und was hast du als Schalter dazwischen hängen?
Zitat von: Markus M. am 03 März 2016, 20:28:27
Damit deaktivierst du das FHEM Gerät, was Sinn macht während du das physische Gerät abschaltest.
ja gut, aber der Befehl
attr deineAbgeschalteteBridge disable 1 darf ja erst dann aktiv sein bzw. 1 sein, wenn die Bridge wirklich aus ist;
und nach dem Einschalten muss ja dann wieder
attr deineAbgeschalteteBridge disable 0 auf 0 geschaltet werden.
Hast du da ein Vorschlag für mich wie ich das realisieren kann? :)
Zitat von: Markus M. am 03 März 2016, 20:28:27
Und was hast du als Schalter dazwischen hängen?
Als Schalter habe ich eine 546E von AVM, diese ist sowieso immer aktiv weil da ein Server über LAN angeschlossen ist,
an die schaltbare Steckdose sitzt halt die MilightBridge!
Zitat von: Tom111 am 03 März 2016, 21:40:14
ja gut, aber der Befehl attr deineAbgeschalteteBridge disable 1 darf ja erst dann aktiv sein bzw. 1 sein, wenn die Bridge wirklich aus ist;
und nach dem Einschalten muss ja dann wieder attr deineAbgeschalteteBridge disable 0 auf 0 geschaltet werden.
Hast du da ein Vorschlag für mich wie ich das realisieren kann? :)
Ähm... ???
Ich nehme an, dass du die Steckdose per FHEM schaltest... Richtig?
Wahrscheinlich Zeitgesteuert oder ähnliches. Also bevor du die Dose abschaltest setzt du die Bridge auf disable 1
attr BridgeAnDerDose disable 1, set Dose offOb nun AT oder notify oder wie auch immer ist dein Bier!
und genau so ander herum... Nachdem die Dose an ist... eventuell mit etwas Verzögerung um eine sichere WLAN-Verbindung zu haben die Bridge wieder aktivieren (disable 0)
set Dose on; sleep(10); attr BridgeAnDerDose disable 0Einfach Einfach
Grüße^^
Gespart = 1,83€ !
pro Jahr?
darüber diskutieren wir schon?
aber wenn ich die Brigde auf Disable stelle, ist die doch komplett deaktiv!
Zitat von: roman1528 am 04 März 2016, 09:38:10
Ähm... ???
Ich nehme an, dass du die Steckdose per FHEM schaltest... Richtig?
ganz genau!
Also ich werde es mal übers WE versuchen.
Danke!
Gruß
Tom
Zitat von: hyper2910 am 04 März 2016, 11:54:42
Gespart = 1,83€ !
pro Jahr?
darüber diskutieren wir schon?
Ja, pro Jahr; sorry ich habe das "/a" im Ergebnis vergessen!
4,75€/a - 2,92€/a = 1,83€/a
Das sind die Kosten für
eine Bridge, wenn ich 10 St. davon habe wären das schon fast 20€/a; und da noch andere Geräte dazukommen muss ich bei jedem dieselbe Überlegung anstellen. Wenn mir das alles egal wäre könnte ich locker jährlich einen dreistelligen Betrag verlieren! Übrigens konnte ich in 10 Jahren mit Hilfe der Technik meinen Stromverbrauch auf nur noch 1/3 senken, ohne dass ich dadurch irgendwelche Einschränkungen habe.
Merke: Kleinvieh macht meist den größten Mist! ;)
Zitat von: hyper2910 am 04 März 2016, 11:54:42
aber wenn ich die Brigde auf Disable stelle, ist die doch komplett deaktiv!
das ist sie ja sowieso wenn die Bridge vom Netz getrennt wird!
Gruß
Tom
Zitat von: roman1528 am 04 März 2016, 09:38:10
Ähm... ???
Ich nehme an, dass du die Steckdose per FHEM schaltest... Richtig?
Wahrscheinlich Zeitgesteuert oder ähnliches. Also bevor du die Dose abschaltest setzt du die Bridge auf disable 1
attr BridgeAnDerDose disable 1, set Dose off
Ob nun AT oder notify oder wie auch immer ist dein Bier!
und genau so ander herum... Nachdem die Dose an ist... eventuell mit etwas Verzögerung um eine sichere WLAN-Verbindung zu haben die Bridge wieder aktivieren (disable 0)
set Dose on; sleep(10); attr BridgeAnDerDose disable 0
Einfach Einfach
Grüße^^
So, hab das ganze mal umgesetzt, nur gibt es da einen Schönheitsfehler.
Sobald das Attribut wechselt steht bei "
Save config" ein Fragezeichen, das will ich so nicht haben.
Danke für den Tipp, aber da muss es noch eine andere Lösung geben !?
Gruß
Tom
Bitte bitte
Die wird es nicht geben...
Das gleiche Problem haben Heating_Control-Nutzer auch, die verschiedene Heating_Control-Profile aktivieren/deaktivieren.
Man ist wohl dabei mit den FHEM-Entwicklern darüber zu sprechen, dass "disable" nicht als config-Änderung gewertet wird und direkt gespeichert werden soll.
Grüße^^
Hallo zusammen,
habe immer noch das Problem das Milight mäßig nichts mehr geht...
Über die Milight app kann ich noch alle Bulbs steuern.
Sobald ich Befehle über FHEM schicke geht die Lampe aus.
Ab und zu kann ich die Lampe zumindest mit set Milight on einschalten... geht aber nach ein paar Sekunden wieder aus...
Hier mal ein Auszug aus dem Log...
2016.03.05 10:19:00 4: Downlight_RGBW_On: Set ON; Ramp: 0
2016.03.05 10:19:00 4: Downlight_RGBW_Dim: Brightness: 4; Ramp: 0; Flags:
2016.03.05 10:19:00 4: Downlight_CmdQueue_Clear
2016.03.05 10:19:00 5: Downlight_HSV_Transition: Prepare Start (actual): 232,100,0@1457169540.61813
2016.03.05 10:19:00 5: MilightDevice_HSVToStr: h:232,s:100,v:0
2016.03.05 10:19:00 4: Downlight_HSV_Transition: Current: 232,100,0
2016.03.05 10:19:00 4: Downlight_HSV_Transition: Set: 232,100,4; Ramp: 0; Flags:
2016.03.05 10:19:00 4: Downlight_HSV_Transition: Set: 232,100,4; No Ramp
2016.03.05 10:19:00 4: Downlight_CmdQueue_Add: h: 232; s: 100; v: 4; Ctrl ; TargetTime: ; QLen: 1
2016.03.05 10:19:00 5: MilightDevice_RGBW_SetHSV: h:232 s:100 v:4 / cv:21 wl:0 cl:2
2016.03.05 10:19:00 5: MilightDevice_HSVToStr: h:232,s:100,v:4
2016.03.05 10:19:00 5: Downlight_CmdQueue_Exec: Next Exec: 1457169540.76222
Update mäßig steht laut Fhem nichts an.
Gruß
Flo
edit:
Hab grad mal die Bridge auf Verbose 5 gestellt. Es wird grusliges ausgegeben :D
2016.03.05 10:25:42 5: MilightBridge_Notify: Triggered by HKucheEG; mode: auto battery: ok desiredTemperature: 12.0 valveposition: 0 12.0 °C RSSI: -38
2016.03.05 10:25:44 5: MilightBridge_Notify: Triggered by HMLAN1; loadLvl: low
2016.03.05 10:25:49 5: MilightBridge_Notify: Triggered by TempBuero; humidity: 42.3
2016.03.05 10:25:49 5: MilightBridge_Notify: Triggered by HMLAN1; loadLvl: low
2016.03.05 10:25:50 5: MilightBridge_Notify: Triggered by Time_Update; Next: 10:26:00
2016.03.05 10:25:51 5: MilightBridge_DoPing: Executing ping
Gruß
hi,
kann dir nur recht geben, seit dem letzten update, funktionieren die milights richtig bescheiden, werde wohl wieder auf eine version von 2015 wechseln.
Zitat von: hyper2910 am 05 März 2016, 11:47:46
hi,
kann dir nur recht geben, seit dem letzten update, funktionieren die milights richtig bescheiden, werde wohl wieder auf eine version von 2015 wechseln.
Das ist wohl die einzige Möglichkeit im Moment!
@Markus M.
Also ich kann das Update auch nicht gutheißen, insbesondere kann ich nicht verstehen warum alle 10 Sekunden ein LOG-Eintrag geschrieben werden muss wenn die MilightBridge mal abwesend ist, es würde
EIN Eintrag vollkommen ausreichen!
Gruß
Tom
Hallo,
vielleicht ne doofe Frage aber hab es eigentlich noch nie gebraucht... wie kann ich denn auf die alte Version Up- bzw Downgraden?
Danke & Gruß
Flo
Zitat von: Niko1987 am 06 März 2016, 13:15:15
Hallo,
vielleicht ne doofe Frage aber hab es eigentlich noch nie gebraucht... wie kann ich denn auf die alte Version Up- bzw Downgraden?
Danke & Gruß
Flo
schau mal ins Verzeichnis
/opt/fhem/restoreDir/Da findest Du Sub-Dirs mit dem Datum, wann Du Updates gefahren hast..
:~/restoreDir$ ll
total 20
drwxrwxrwx 5 fhem dialout 4096 Mar 5 14:27 .
drwxrwxrwx 25 fhem root 4096 Mar 6 13:17 ..
drwxr-xr-x 3 fhem dialout 4096 Mar 1 14:20 2016-03-01
drwxr-xr-x 3 fhem dialout 4096 Mar 2 08:09 2016-03-02
drwxr-xr-x 3 fhem dialout 4096 Mar 5 14:27 2016-03-05
In den Sub-Dirs gibt es den Ordner FHEM
~/restoreDir/2016-03-01/FHEM$ ll
total 496
drwxr-xr-x 2 fhem dialout 4096 Mar 1 14:20 .
drwxr-xr-x 3 fhem dialout 4096 Mar 1 14:20 ..
-rw-r--r-- 1 fhem dialout 26006 Mar 1 14:20 10_MYSENSORS_DEVICE.pm
-rw-r--r-- 1 fhem dialout 13899 Mar 1 14:20 30_MilightBridge.pm
-rw-r--r-- 1 fhem dialout 13800 Mar 1 14:20 47_OBIS.pm
-rw-r--r-- 1 fhem dialout 54598 Mar 1 14:20 70_XBMC.pm
-rw-r--r-- 1 fhem dialout 208537 Mar 1 14:20 72_FRITZBOX.pm
-rw-r--r-- 1 fhem dialout 56332 Mar 1 14:20 74_Unifi.pm
-rw-r--r-- 1 fhem dialout 111763 Mar 1 14:20 controls_fhem.txt
Da findest Du die "alten" Module..
Und dann das Module nach
/opt/fhem/FHEM kopieren.
Hallo,
Danke das hat soweit geklappt.
Jedoch funktioniert immer noch nichts ;P
Gruß
Zitat von: Niko1987 am 06 März 2016, 13:15:15
Hallo,
vielleicht ne doofe Frage aber hab es eigentlich noch nie gebraucht... wie kann ich denn auf die alte Version Up- bzw Downgraden?
Danke & Gruß
Flo
https://github.com/mhop/fhem-mirror/commits/master/fhem/FHEM/30_MilightBridge.pm
Such dir eine Version aus, dann daneben auf
<> klicken und den kompletten Codetext kopieren
und deine fhem/FHEM/30_MilightBridge.pm durch den vorhandenen Code ersetzen!
Aber ich bin mir sicher, dass Markus oder Mattwire die genannten Komplikationen in den Griff bekommen werden.
Gruß
Tom
Hallo,
Danke dir aber ich hab das ganze jetzt rausgeschmissen und steuere meine Milights über das Wifilight Modul.
Das klappt einwandfrei.
Gruß
Flo
Bitte ausprobieren
- Längere Reconnectzeit (1 Minute) bei Ping
- Broadcast wieder aktiviert
Naja, schon besser, aber ich bleibe bei der alten Version von 2015.
Es sind ganz einfach zu viele LOG-Einträge und sollte ich mal für 2 Wochen in Urlaub sein hätte ich über 40.000 Einträge, wo mir jeder einzelne sagt dass die Bridge nicht erreichbar ist, ich glaube bei der Anzahl würde ich sogar Probleme mit dem Speicher bekommen.
2016.03.06 22:12:05 1: Timeout for MilightBridge_DoPing reached, terminated process 20302
2016.03.06 22:12:05 3: BlockingCall for MiLight was aborted
2016.03.06 22:13:17 1: Timeout for MilightBridge_DoPing reached, terminated process 20366
2016.03.06 22:13:17 3: BlockingCall for MiLight was aborted
2016.03.06 22:14:29 1: Timeout for MilightBridge_DoPing reached, terminated process 20434
2016.03.06 22:14:29 3: BlockingCall for MiLight was aborted
2016.03.06 22:16:53 1: Timeout for MilightBridge_DoPing reached, terminated process 20607
2016.03.06 22:16:53 3: BlockingCall for MiLight was aborted
2016.03.06 22:18:05 1: Timeout for MilightBridge_DoPing reached, terminated process 20680
2016.03.06 22:18:05 3: BlockingCall for MiLight was aborted
Danke für deine Bemühungen, aber das bringt mir nichts!
Gruß
Tom
Zitat von: Tom111 am 06 März 2016, 22:25:01
Danke für deine Bemühungen, aber das bringt mir nichts!
Wie weiter oben schon mal erklärt, gibt es in deinem Fall mit dem Logging keinen Fehler im Modul. Das ist ein Bedienfehler.
Wenn du keine Logeinträge möchtest, musst du einfach nur das FHEM Device deaktivieren wenn du die Bridge abschaltest und es wieder aktivieren wenn du sie anschaltest. Oder du deaktivierst das Logging für das Device.
Das mit dem Farbwechsel
muss ich mir noch ansehen, das bekomme ich sicher noch hin. sollte mit dem Anhang funktionieren.
Hi Markus,
das mit den Logeinträgen nervt mich auch.
Ich habe eigentlich alles versucht mit verbose, aber die Logeinträge kommen alle 10sec.
Ich schalte auch meine Bridge nicht ab oder ähnliches.
Zitat von: Markus M. am 21 Februar 2016, 23:37:35
Ja, du legst ein weiteres Device mit A statt 1-4 an.
define rgbw_allgroups MilightDevice RGBW milightbridge A
Leider bin erst gestern dazu gekommen, die Milight Lampen fest in mein Wohnzimmer zu installieren. Sorry für die späte Rüclmeldung. Ich habe ein weiteres MilightDevice (Slot A) wie von dir vorgeschlagen angelegt. Allerdings habe ich den komischen Effekt, dass ich ausschließlich blaues oder weißes Licht einstellen kann, egal welche Farbe ich einstelle. Das Dimmen funktioniert ohne Probleme, aber wie gesagt, ich kann nur diese beiden Farben über das neue MilightDevice einstellen. Wenn ich die Kanäle einzeln (Slot 5-8) ansteuere, kann ich alles perfekt steuern. Es ist nur bei dem neuen (Slot A) MilightDevice. Habt ihr eine Idee, was es sein könnte?
Gruß Timothee
Zitat von: hyper2910 am 07 März 2016, 08:20:04das mit den Logeinträgen nervt mich auch.
Ich habe eigentlich alles versucht mit verbose, aber die Logeinträge kommen alle 10sec.
Ich schalte auch meine Bridge nicht ab oder ähnliches.
Hat deine Bridge Verbindungsprobleme?
Die Fehler kommen leider direkt aus dem Blocking das Matt eingebaut hat.
Ich weiss nicht ob und wie ich die aus Milight unterdrücken könnte.
Mit dem Modul eins weiter oben wird die Reconnect Zeit hochgesetzt, du kannst aber zusätzlich auch mal das Intervall über das Attribut
checkInterval hochsetzen.
Zitat von: Timothee am 07 März 2016, 08:27:52Leider bin erst gestern dazu gekommen, die Milight Lampen fest in mein Wohnzimmer zu installieren. Sorry für die späte Rüclmeldung. Ich habe ein weiteres MilightDevice (Slot A) wie von dir vorgeschlagen angelegt. Allerdings habe ich den komischen Effekt, dass ich ausschließlich blaues oder weißes Licht einstellen kann, egal welche Farbe ich einstelle. Das Dimmen funktioniert ohne Probleme, aber wie gesagt, ich kann nur diese beiden Farben über das neue MilightDevice einstellen. Wenn ich die Kanäle einzeln (Slot 5-8) ansteuere, kann ich alles perfekt steuern. Es ist nur bei dem neuen (Slot A) MilightDevice. Habt ihr eine Idee, was es sein könnte?
Das klingt seltsam. Das Define sieht ok aus.
Wie steuerst du? HSV oder RGB? Bei mir funktioniert beides problemlos - bitte mal ausprobieren.
Was sagen deine Attribute
colorCast und
gamma?
Gruss, Markus
sind wohl auch zwei unterschiedliche Logeintäge:
2016.03.01 00:00:05 4: BlockingCall (MilightBridge_DoPing): created child (25252), uses telnetForBlockingFn_1456772350 to connect back
2016.03.01 00:00:05 4: Connection accepted from telnetForBlockingFn_1456772350_127.0.0.1_38711
2016.03.01 00:00:09 4: BlockingCall (MilightBridge_DoPing): created child (25256), uses telnetForBlockingFn_1456772350 to connect back
2016.03.01 00:00:09 4: Connection accepted from telnetForBlockingFn_1456772350_127.0.0.1_38712
Zitat von: Markus M. am 07 März 2016, 11:48:09
Hat deine Bridge Verbindungsprobleme?
Die Fehler kommen leider direkt aus dem Blocking das Matt eingebaut hat.
Ich weiss nicht ob und wie ich die aus Milight unterdrücken könnte.
Mit dem Modul eins weiter oben wird die Reconnect Zeit hochgesetzt, du kannst aber zusätzlich auch mal das Intervall über das Attribut checkInterval hochsetzen.
Hi,
die beiden Bridges laufen einwandfrei, nur mit der neuen Version kommen aufeinmal diese Logs.
Zitat von: Markus M. am 07 März 2016, 01:06:09
Wie weiter oben schon mal erklärt, gibt es in deinem Fall mit dem Logging keinen Fehler im Modul. Das ist ein Bedienfehler.
Wenn du keine Logeinträge möchtest, musst du einfach nur das FHEM Device deaktivieren wenn du die Bridge abschaltest und es wieder aktivieren wenn du sie anschaltest. Oder du deaktivierst das Logging für das Device.
wenn ich das Logging deaktiviere,
attr MiLight verbose 0bekomme ich dennoch LOG-Einträge:
2016.03.07 15:53:56 3: telnetForBlockingFn_1457362436: port 37192 opened
2016.03.07 15:54:49 1: Timeout for MilightBridge_DoPing reached, terminated process 22426
2016.03.07 15:55:13 1: Timeout for MilightBridge_DoPing reached, terminated process 22464
2016.03.07 15:55:25 1: Timeout for MilightBridge_DoPing reached, terminated process 22471
2016.03.07 15:55:49 1: Timeout for MilightBridge_DoPing reached, terminated process 22480
2016.03.07 15:56:01 1: Timeout for MilightBridge_DoPing reached, terminated process 22502
2016.03.07 15:56:13 1: Timeout for MilightBridge_DoPing reached, terminated process 22512
2016.03.07 15:56:37 1: Timeout for MilightBridge_DoPing reached, terminated process 22531
2016.03.07 15:56:49 1: Timeout for MilightBridge_DoPing reached, terminated process 22537
2016.03.07 15:57:01 1: Timeout for MilightBridge_DoPing reached, terminated process 22569
2016.03.07 15:57:13 1: Timeout for MilightBridge_DoPing reached, terminated process 22579Zitat von: Markus M. am 07 März 2016, 01:06:09
Das mit dem Farbwechsel muss ich mir noch ansehen, das bekomme ich sicher noch hin. sollte mit dem Anhang funktionieren.
OK, anstatt auf 0 springt die Helligkeit jetzt auf 100%, ist zwar nicht perfekt, aber damit kann ich leben.
Wirst du diese Version noch hochladen oder muss ich "
31_MilightDevice.pm" in "
exclude_from_update" setzen?
Gruß
Tom
Hi, da ich mich mit milight überhaupt nicht auskenne, frag ich hier mal.
Brauch man eine besondere Fassung oder sowas oder kann ich z.b die hier
4 x 2.4G RF RGBW Warm White LED Lamp GU10 4W 220V Wireless Control by Mi-Light WiFi Remote Controller iPhone iPad Android Smartphone Tablet https://www.amazon.de/dp/B016YGYPNQ/ref=cm_sw_r_cp_awd_w.z3wbBGHADFS
In einer normalen Gu10 benutzen .
Brauche ich dann noch muss? Wie sende ich dir befehle dann über fhem?
Danke
Gesendet von iPhone mit Tapatalk
Zitat von: hyper2910 am 07 März 2016, 13:19:55
sind wohl auch zwei unterschiedliche Logeintäge:
2016.03.01 00:00:05 4: BlockingCall (MilightBridge_DoPing): created child (25252), uses telnetForBlockingFn_1456772350 to connect back
2016.03.01 00:00:05 4: Connection accepted from telnetForBlockingFn_1456772350_127.0.0.1_38711
Kein Fehler sondern eine normale Ausgabe, bitte globales Loglevel runtersetzen.
Alles über 2 global macht keinen Sinn!
Zitat von: Tom111 am 07 März 2016, 15:58:49
wenn ich das Logging deaktiviere,
attr MiLight verbose 0
bekomme ich dennoch LOG-Einträge
Du musst das Modul deaktivieren während du die Bridge abschaltest.
Einen anderen Weg gibt es nicht.
ZitatOK, anstatt auf 0 springt die Helligkeit jetzt auf 100%, ist zwar nicht perfekt, aber damit kann ich leben.
Wirst du diese Version noch hochladen oder muss ich "31_MilightDevice.pm" in "exclude_from_update" setzen?
In RGB ist die Helligkeit immer enthalten. FF = volle Helligkeit.
Der Fix dafür ist morgen im Update.
Gruß, Markus
Zitat von: Markus M. am 07 März 2016, 11:48:09
Das klingt seltsam. Das Define sieht ok aus.
Wie steuerst du? HSV oder RGB? Bei mir funktioniert beides problemlos - bitte mal ausprobieren.
Was sagen deine Attribute colorCast und gamma?
Normalerweise über RGB, hab aber beides probiert - gleicher Effekt.
Mir fällt grad auf, dass der Internal "INIT" bei dem Allgroup-MilightDevice ne 0 anzeigt. Bei den "echten" Lampen steht dort ne 1.
In der Detailansicht sind die Attribute bei allen nicht gesetzt. Wenn ich ein List mit dem jeweilige Gerät ausführe, werden bei den "echten" Lampen unter den beiden Attribute ausschließlich Zahlen Zeile für Zeile ausgegeben. Bei dem Allgroup-MilightDevice hingegen wird für colorCast nichts ausgegeben, für gamma allerdings das gleiche wie bei den "echten".
Hab grad mal das Modul 31_MilightDevice aktualisiert... und schon funktionierts :)
Allerdings steht bei dem Allgroup-MilightDevice immer noch eine 0?
UPDATE:
- Neues Feature: "HSV" Transitions für WWCW Birnen, um Helligkeit und Temperatur gleichzeitig zu steuern
Dazu einfach HSV Werte wie z.B. 3000,1,100 verwenden
- Bugfix: RGB Ansteuerung sollte nun wieder funktionieren
- Fix: Weniger Perl Warnungen beim Start
Hallo,
ich habe seit kurzem eine Milight Bridge v4 und einen RGB controller.
Die Milight bridge kann ich problemlos in FHEM definieren, das funktioniert soweit.
Ich habe aber das Problem das ich das Milight device nicht als RGB controller anlernen kann. Dann kommt immer die Meldung ich muss für RGB den Slot 0 auswählen. Wenn ich den Controller dann auf den slot 0 setzte, habe ich aber keine Funktion. Mit der Android app habe ich den Cobntroller auf Zone 1 angelernt. Per App funktioniert alles einwandfrei, nur mit Fhem kann ich nichts steuern.
Mache ich da jetzt irgendwo etwas komplett falsch?
Danke
Ja, du hast mit Sicherheit einen RGBW Controller und keinen RGB Controller.
Guten Abend,
was macht Dich da so sicher?
Ich habe definitiv einen RGB Controller. Soll ich dir ein Foto schicken?
Gruß
RGB Controller gibt es eigentlich seit Ewigkeiten nicht mehr zu kaufen.
Wenn du ihn in der App auf Slot 1 von 4 eingerichtet hast, musst du das auch in FHEM so definieren.
Und zwar als RGBW. Probiers einfach mal aus.
Hallo,
Dann habe ich wohl ein sehr sehr altes Modul gekauft über Amazon, komisch.
also wenn ich es als RGBW auf slot 5 setzte klappt es, danke erst mal.
Allerdings ist das Verhalten eher unschön. Manchmal schaltet er sich nicht aus, sondern wird dann nur ganz dunkel. Wenn ich set off 1, oder set on 1 eingebe, also ausschalten bzw. einschlaten innerhalb 1s, dann braucht er wesentlich länger. bestimmt um die 5s und das dimmer passiert sehr ungleichmäßig und sehr ruckartig.
Mit der App funktioniert alles super, am Empfang kann es also nicht liegen. Ich denke das Verhalten ist nicht so gedacht, oder ist das normal?
Gruß
ZitatIch habe definitiv einen RGB Controller. Soll ich dir ein Foto schicken?
Ja bitte.
vg
joerg
Hallo
Ich kann irgendwie keine Bilder anhängen. Da kommt immer eine Fehlermeldungen das die Datei nicht gespeichert werden konnte.
Gruß
Dirk
Danke
Auch ich habe mir einen RGB Controller besorgt nachdem ich vor kurzem das Problem hatte das der RGBW Controller bei RGB Stripes mir immer das Licht ausgedreht hat wenn ich alle auf weiss haben wollte das Problem ist nun gelöst der RGB Controller sowie der RGB Stripe können natürlich kein weiss aber der RGB Controller geht dann einfach in so einem Blau weissen Licht an super! :).
Bild im Anhang.
Bzgl. der RGB- und RGBW- Controller thematik habe ich das auch noch mal bei meinem Lampen Händler geprüft und er hat auch schon immer beide Varianten im Angebot gehabt einen RGB sowie einen RGBW Controller...
In FHEM musste ich ihn aber auch als RGBW in einer RGBW Zone definieren ansonsten wollte es nicht tun...
Danke für das Bild Speex, ich hoffe mir glauben nun alle ;) (Ich kann immer noch keine Dateien hochladen >:()
Wie komme ich jetzt aber bei dem Problem mit dem ruckeligen Dimmen und komischen ein- und ausschaltverhalten weiter.
Wenn das hier sonst keiner hat müsste es ja irgendwo in meinem System einen Fehler geben. Wie komme ich dem aber auf die Spur. Hat da jemand eine Idee?
Wie gesagt funktioniert per App alles super. Dann müsste es ja irgendwie an der FHEM Schnittstelle liegen.
Definiert habe ich die Bridge und devices so:
#-------------------------------------------Milight-----------------------------------------------------
define MilightBridge_1 MilightBridge 192.168.2.114
attr MilightBridge_1 checkInterval 10
attr MilightBridge_1 event-on-change-reading state
attr MilightBridge_1 port 8899
attr MilightBridge_1 protocol udp
attr MilightBridge_1 room Server
attr MilightBridge_1 sendInterval 100
define LED_Kueche MilightDevice RGBW MilightBridge_1 5
attr LED_Kueche IODev MilightBridge_1
attr LED_Kueche devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
attr LED_Kueche event-on-change-reading state,transitionInProgress
attr LED_Kueche group Licht
attr LED_Kueche lightSceneParamsToSave hsv
attr LED_Kueche restoreAtStart 1
attr LED_Kueche room Küche
attr LED_Kueche webCmd on:off:dim:hue:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffff00
#-------------------------------------------------------------------------------------------------------
Danke
Faszinierend - das scheint eine Art RGBW Controller zu sein bei dem der Weisskanal fehlt.
Probier mal attr MilightBridge_1 sendInterval 200
Hallo,
Ich habe den Wert jetzt auf 200 gesetzt. Gefühlt ist es etwas besser. Aber es ist immer noch so das beim einschalten erst eine sehr geringe Helligkeit angeht, und dann erst auf 100% geschaltet wird. Das dann innerhalb 1s. Beim Ausschalten genau andersherum. Das Dimmen ist jetzt etwas besser geworden, aber stufenlos würde ich es nicht nennen. Zumindest gibt es jetzt keine grossen Sprünge mehr. Hat noch jemand Tips wie ich das Einschalten optimieren kann. Ich schalte per set on ein, ohne Zeitangabe.
Zitat von: FEHMPiDi am 22 März 2016, 09:43:46Aber es ist immer noch so das beim einschalten erst eine sehr geringe Helligkeit angeht, und dann erst auf 100% geschaltet wird. Das dann innerhalb 1s. Beim Ausschalten genau andersherum.
Gibt es die Attribute defaultRampOn/defaultRampOff?
Falls ja: Löschen
Nein, gibt es nicht.
Vielleicht wird der RGB controller anders angesteuert als ein RGBW? Kann es sein das er deswegen das komische Verhalten zeigt?
Für mich sieht es so aus als ob die Befehle zu langsam am Controller ankommen. Kann es sein das mein RasPi zu langsam ist? Kann man das irgendwie checken?
Gruß und Danke
Hallo zusammen,
ich bin mir jetzt nicht sicher, ob die Frage hier gut aufgehoben ist, oder besser im Smartvisu Bereich.
Ich versuche es einfach mal hier.
Als erstes, Fhem ist auf dem neuesten Stand.
Die Bridge inkl. Controller (RGB Controller an Slot 5) sind konfiguriert und lassen sich unter Fhem 100%ig bedienen.
Auch via Smartvisu funktioniert die Steuerung (An/Aus, Farbwahl über Colourdisc und die Dimmfunktion). Was leider nicht klappt, ist die automatische Aktualisierung des Sliders (Dimmen/Brightnesswert) und der Farbeinstellung.
Ich habe mal 3 Bilder angehängt zur besseren Erklärung.
Bild 1: Ausgangslage (LEDs sind aus)
Bild 2: Nach Klick auf den Schalter gehen die LEDs an (blau 100%) aber im Browser ist dieses nicht zu sehen.
Bild 3: Nach Browser Refresh sieht es so aus, wie es sein soll.
Wie gesagt, beim steuern direkt unter Fhem erfolgt die Aktualisierung des Status sofort ohne Refresh.
Steuert evtl. jemand seine Milights via Smartvisu und hat eine Ahnung woran das liegen könnte?
Hier noch meine Auszüge aus meiner Fhem.cfg und die Definitionen der GADs etc...
define MilightBridge MilightBridge 192.168.0.230
attr MilightBridge checkInterval 10
attr MilightBridge event-on-change-reading state
attr MilightBridge port 8899
attr MilightBridge protocol udp
attr MilightBridge sendInterval 100
define RGB_Controller1 MilightDevice RGBW MilightBridge 5
attr RGB_Controller1 IODev MilightBridge
attr RGB_Controller1 devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
attr RGB_Controller1 event-on-change-reading state,transitionInProgress
attr RGB_Controller1 lightSceneParamsToSave hsv
attr RGB_Controller1 restoreAtStart 1
attr RGB_Controller1 updateGroupDevices 1
attr RGB_Controller1 verbose 0
attr RGB_Controller1 webCmd on:off:dim:hue:night:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffff00
Der Dimmer und die Colourdisc sind wie folgt definiert
{{ device.dimmer('RGB_Controller1_1_Dimmer1', 'Dimmer', 'RGB_Controller1_1_Dimmer_sw', 'RGB_Controller1_1_Dimmer_sl', 0, 100 ,1) }}
{{ basic.colordisc('RGB_Controller1_1_Farbwahl', 'RGB_Controller1_1_Farbwahl_r.sw', 'RGB_Controller1_1_Farbwahl_g.sw', 'RGB_Controller1_1_Farbwahl_b.sw') }}
RGB_Controller1_1_Farbwahl_g.sw als GAD
device RGB_Controller1
reading state
converter OnOff
cmd set state
RGB_Controller1_1_Dimmer_sl als GAD
device RGB_Controller1
reading brightness
converter NumDirect
cmd set brightness
Vielen Dank im Vorraus
Knurb
Du musst dein event on change reading attribut in den MilightDevices um die werte anpassen die aktualisiert werden sollen bzw. ein event erzeugen das wird dann wieder an fronthem übertragen.
Bei mir sieht das zb. so aus:
attr RGB_Controller1 event-on-change-reading state,transitionInProgress,rgb,brightness
Dann sollten sich die Slider auch in SmartVisu entsprechend verändern.
Vielen Dank speex.
Läuft jetzt 1A !!!!
Hallo,
ich habe das Ganze jetzt mal mit dem Wifilight modul getestet. Damit scheint es besser zu funktionieren aber auch nicht perfekt.
Ist es denn normal das ich beim Dimmer deutliche Stufen sehe? Beim Dimmen mit der App geht das ganze ja komplett stufenlos.
Vielleicht erwarte ich auch einfach zuviel?
Speex, wie funktioniert denn dein RGB Controller. Ist das Dimmer wirklich stufenlos und das Ein- und Ausschalten auch?
Auf meiner Wifi Bridge läuft übrigens die SW-Version V1.0.04a-JCY-1. Kannst Du mal gucken welche Version Deine Bridge hat, vielleicht liegt es daran?
Hat noch jemand eine Idee wie ich bei meinem Problem weiter komme?
Danke
Hallo FHEMPiDi!
Auch ich verwende das Milight System und bin nur eingeschränkt zufrieden. Die Stabilität einer der beiden Bridges, die ich betreibe, ist mangelhaft und ich hatte auch Probleme, dass Befehle von der Bridge zum RGB Controller nicht oder ,,unvollständig" ankamen.
Wie weit sind denn Controller und Bridge voneinander entfernt? Die Reichweite ist nämlich nicht berauschend habe ich festgestellt. Auch habe ich die Erfahrung gemacht, dass die Controller extrem störempfindlich sind – direkt neben einer 230V Leitung platziert empfange sie teilweise gar nichts. Dass die 50Hz der Leitung das Funksystem stören schließe ich aus, aber irgendwas bringt den Controller dann doch durcheinander. Hast du schon versucht, die Geräte umzuplazieren? Versuchsweise mal direkt nebeneinander?
Aus meiner Sicht ist das Milight Zeugs recht unausgereiftes Spielzeug, dafür aber halt auch preislich weit von "hochwertigeren" Systemen namhafter Hersteller entfernt. Wunder kann man da keine erwarten - aber funktionieren sollte es halt schon.
BTW: Die RGB (ohne ,,W") Controller sind durchaus in einschlägigen Shops noch erhältlich. Auch ich musste mit dem FHEM Modul sie als RGBW konfigurieren (Ab Slot 5) – kam zufällig irgendwann nach rumprobieren zum Erfolg.
Gruß Tobi
Hallo,
Danke für deine Erfahrungen. Reichweiten oder Kommunikationsprobleme schließe ich eigentlich aus, da die Steuerung per App ja 100% funktioniert. Oder gibt es bei den übertragenen Befehlen Unterschiede zwischen Fhem und app? Ich vermute das daß Problem eher an Fhem oder meinen RasPi liegt. Ich weiß nur nicht wie ich dahinterkommen kann was das Problem ist.
Hey Fhempidi, tja bevor du das beschrieben hast ist mir das garnicht wirklich aufgefallen aber du hast recht.
Wenn ich per Fhem die Dimmwerte ändere sind hier klar stufen zu erkennen, wenn ich das ganze per Milight app mache läuft das auf alle fälle sehr smooth auch farbwechsel.
Ich vermute das liegt einfach an der tatsache dass das milight Modul reverse engineered ist?
Wo lest ihr denn eigentlich die Firmware aus der Bridge aus?
Ansonsten fallen mir zu dem Thema noch 2 Links auf die ich vor kurzem mal gestoßen bin, vielleicht ist da ja was bei was vorher auf der strecke blieb:
http://torsten-traenkner.de/wissen/smarthome/openmilight.php (http://torsten-traenkner.de/wissen/smarthome/openmilight.php)
https://hackaday.io/project/5888-reverse-engineering-the-milight-on-air-protocol (https://hackaday.io/project/5888-reverse-engineering-the-milight-on-air-protocol)
Aber im Endeffekt sind das die gleichen Ansätze...
Hm, dass es Probleme gibt, die bei App-Steuerung nicht auftreten, aber von FHEM aus, hatte ich auch beobachtet. Stichwort Stabilität der Bridges: Hier habe ich fast nie Probleme mit meiner Smartphone App, über FHEM ist aber eine meiner Bridgets regelmäßig disconnected.
Ich werde mal in einer ruhigen Stunde versuchen den UDP Verkehr zwischen FHEM und der Bridge sowie der App und der Bridge via Wireshalk o.ä. zu tracen und vergleichen. Würde zwar schon vermuten, dass beide identisch arbeiten. Aber irgendeinen Grund muss das unterschiedliche Verhalten ja haben. Inwieweit die hier beschriebenen Probleme des "Dimmens" (die ich auch sehe) hierin auch begründet liegen - keine Ahnung.
Dauert aber sicher noch etwas bis ich dazukomme... Erstmal Ostereier suchen ;)
Gruß
Tobi
Hallo zusammen,
erstens, die Module funktionieren wunderbar bei mir.
Was mir aufgefallen ist, ich habe zwei Bridges, diese arbeiten normal, programmiert und angelernt habe ich die Lampen bzw. Controller über die Fernbedienung.
Nur erscheinen bei der zweiten Bridge in den Readings unter Slot keine Device.
Teilweise sind die Device der zweiten Bridge in den Readings der ersten zu sehen, laut Def wird aber als IODEV die zweite genutzt.
Ist das so richtig?
Seit langen mal wieder in meinen Log geschaut und festgestellt, dass ich Tonnen an folgenden Fehlern habe:
Timeout for MilightBridge_DoPing reached, terminated process 799
Woran kann das liegen, hatte ich früher nicht?
Hast Du eine fixe IP vergeben? Oder per DHCP - da kann sich bei Überschneidung des ablaufenden Leases die IP ändern... Ping die IP doch mal von Hand an bzw. versuche vom Browser aus zuzugreifen - landest Du auf dem korrekten Gerät?
Die Meldung ist normal und kommt von der Ping Umstellung auf NonBlocking. Sie kommt nicht aus dem MiLight Modul.
Vorher war da einfach nur Unreachable - beobachte mal die Verbindung der Bridge.
Kann ich das denn irgendwo ändern?
keiner eine Idee zu den Readings der Bridge?
Gibt es eigentlich eine Möglichkeit bei einem MilightDevice mit on-for-timer den night-modus zu schalten?
Das ganze mit +at zu machen finde ich etwas unschön... und eventMap wird wohl nicht funktionieren :(
Zitat von: Markus M. am 06 April 2016, 09:28:51
Die Meldung ist normal und kommt von der Ping Umstellung auf NonBlocking. Sie kommt nicht aus dem MiLight Modul.
Vorher war da einfach nur Unreachable - beobachte mal die Verbindung der Bridge.
Hi,
habe das auch.
GIbt es eine Möglichkeit das zu ändern / raus zu nehmen?
Die Pings und damit den kompletten Status der Bridge nach der Initialisierung optional zu machen und die Befehle wie in der App auf gut Glück abzufeuern wäre eine Idee.
Sent from my iPhone using Tapatalk
Das kann aber nur der Modul Entwickler oder
Gesendet von meinem Huawei Honor 7
Das kann theoretisch einer der beiden Modulentwickler, aktuell aber nur Matt weil ich die nächsten 2 Wochen unterwegs bin ;)
@Matt: Can you have a look at the ping mechanism and make it completely optional (maybe once the bridge has been initially found)?
Sent from my iPhone using Tapatalk
Bei mir kommt die Fehlermeldung auch, mehrmals pro Minute - obwohl die Milightbridge immer und ständig erreichbar ist. Funktioniert ansonsten auch alles ziemlich gut, eben bis auf diese Fehlermeldung.
016.05.13 13:03:54 1: Timeout for MilightBridge_DoPing reached, terminated process 26986
2016.05.13 13:03:54 3: BlockingCall for MiLightBridge was aborted
2016.05.13 13:04:06 1: Timeout for MilightBridge_DoPing reached, terminated process 26987
2016.05.13 13:04:06 3: BlockingCall for MiLightBridge was aborted
2016.05.13 13:04:18 1: Timeout for MilightBridge_DoPing reached, terminated process 26988
2016.05.13 13:04:18 3: BlockingCall for MiLightBridge was aborted
2016.05.13 13:26:51 1: Timeout for MilightBridge_DoPing reached, terminated process 27445
2016.05.13 13:26:51 3: BlockingCall for MiLightBridge was aborted
2016.05.13 14:28:02 1: Timeout for MilightBridge_DoPing reached, terminated process 30330
2016.05.13 14:28:02 3: BlockingCall for MiLightBridge was aborted
Fehler leider immer noch nicht behoben:
2016.06.26 11:22:30 1: Timeout for MilightBridge_DoPing reached, terminated process 28083
2016.06.26 11:22:30 3: BlockingCall for MiLight was aborted
2016.06.26 11:22:54 1: Timeout for MilightBridge_DoPing reached, terminated process 28115
2016.06.26 11:22:54 3: BlockingCall for MiLight was aborted
2016.06.26 11:23:06 1: Timeout for MilightBridge_DoPing reached, terminated process 28134
2016.06.26 11:23:06 3: BlockingCall for MiLight was aborted
2016.06.26 11:23:18 1: Timeout for MilightBridge_DoPing reached, terminated process 28139
2016.06.26 11:23:18 3: BlockingCall for MiLight was aborted
2016.06.26 11:23:30 1: Timeout for MilightBridge_DoPing reached, terminated process 28145
2016.06.26 11:23:30 3: BlockingCall for MiLight was aborted
2016.06.26 11:23:42 1: Timeout for MilightBridge_DoPing reached, terminated process 28177
2016.06.26 11:23:42 3: BlockingCall for MiLight was aborted
2016.06.26 11:24:06 1: Timeout for MilightBridge_DoPing reached, terminated process 28195
2016.06.26 11:24:06 3: BlockingCall for MiLight was abortedOb man das nun als Fehler bezeichnen kann oder nicht, für mich ist es ein absolutes No-Go wie bereits schon diskutiert:
Zitathttps://forum.fhem.de/index.php/topic,30638.msg421098.html#msg421098
Naja, dan bleibt "30_MilightBridge.pm" weiterhin "exclude_from_update"!
Mit der uralt Version hab ich glücklicherweise keine Probleme!
kann jemand ein altes modul zur verfügung stellen
Hi, nachdem ich nun schon einige Zeit das UFO mit Wifilight ansteuere habe ich nun für einen Umbau W/WW LED Lampen gekauft und möchte diese mit einem Mi-Light W/WW Controller ansteuern.
Jetzt habe ich ja das WifiLight und dieses Modul hier zur Auswahl. Was soll ich probieren? Ich möchte die Lampen über 2 Mi-Light Controller und einer Bridge ansteuern und ja die Möglichkeit zur Farbtemperaturänderung nutzen.
Grüße
Dirk
Ich habe das MiLight Modul nun verwendet und bin grundsätzlich sehr zufrieden damit. Es macht was es soll.
Nur 2 Punkte:
1. Wie kann ich den Bereich der Farbtemperatur beim verwenden der White Controller verändern? Meine Lampen haben einen Bereich von 2700k - 6000k. Das Modul stellt aber von 3000k - 6500k ein.
2. Nach dem Test und Ausschalten der Geräte ist mir das gleiche Problem entstanden wie bei meinen Vorrednern.
2016.08.17 00:30:21 1: Timeout for MilightBridge_DoPing reached, terminated process 14737
2016.08.17 00:30:21 3: BlockingCall for MilightBridgeKu was aborted
2016.08.17 00:30:33 1: Timeout for MilightBridge_DoPing reached, terminated process 14740
2016.08.17 00:30:33 3: BlockingCall for MilightBridgeKu was aborted
2016.08.17 00:30:45 1: Timeout for MilightBridge_DoPing reached, terminated process 14743
2016.08.17 00:30:45 3: BlockingCall for MilightBridgeKu was aborted
2016.08.17 00:31:09 1: Timeout for MilightBridge_DoPing reached, terminated process 14753
2016.08.17 00:31:09 3: BlockingCall for MilightBridgeKu was aborted
2016.08.17 00:31:21 1: Timeout for MilightBridge_DoPing reached, terminated process 14754
2016.08.17 00:31:21 3: BlockingCall for MilightBridgeKu was aborted
2016.08.17 00:31:45 1: Timeout for MilightBridge_DoPing reached, terminated process 14760
2016.08.17 00:31:45 3: BlockingCall for MilightBridgeKu was aborted
2016.08.17 00:31:57 1: Timeout for MilightBridge_DoPing reached, terminated process 14761
2016.08.17 00:31:57 3: BlockingCall for MilightBridgeKu was aborted
2016.08.17 00:32:09 1: Timeout for MilightBridge_DoPing reached, terminated process 14772
2016.08.17 00:32:09 3: BlockingCall for MilightBridgeKu was aborted
2016.08.17 00:33:21 1: Timeout for MilightBridge_DoPing reached, terminated process 14794
2016.08.17 00:33:21 3: BlockingCall for MilightBridgeKu was aborted
2016.08.17 00:33:36 1: Timeout for MilightBridge_DoPing reached, terminated process 14796
2016.08.17 00:33:36 3: BlockingCall for MilightBridgeKu was aborted
2016.08.17 00:34:00 1: Timeout for MilightBridge_DoPing reached, terminated process 14803
2016.08.17 00:34:00 3: BlockingCall for MilightBridgeKu was aborted
2016.08.17 00:34:12 1: Timeout for MilightBridge_DoPing reached, terminated process 14810
2016.08.17 00:34:12 3: BlockingCall for MilightBridgeKu was aborted
2016.08.17 00:34:24 1: Timeout for MilightBridge_DoPing reached, terminated process 14813
2016.08.17 00:34:24 3: BlockingCall for MilightBridgeKu was aborted
2016.08.17 00:34:51 1: Timeout for MilightBridge_DoPing reached, terminated process 14818
2016.08.17 00:34:51 3: BlockingCall for MilightBridgeKu was aborted
2016.08.17 00:35:15 1: Timeout for MilightBridge_DoPing reached, terminated process 14880
2016.08.17 00:35:15 3: BlockingCall for MilightBridgeKu was aborted
2016.08.17 00:35:27 1: Timeout for MilightBridge_DoPing reached, terminated process 14881
2016.08.17 00:35:27 3: BlockingCall for MilightBridgeKu was aborted
2016.08.17 00:35:54 1: Timeout for MilightBridge_DoPing reached, terminated process 14887
Da ich die Geräte erst in einigen Wochen fest verbaue habe ich halt einfach die devices wieder gelöscht.
Nun ist aber auch das hier permanent im Log:
2016.08.17 00:42:03 1: ERROR: empty name in readingsBeginUpdate
2016.08.17 00:42:03 3: stacktrace:
2016.08.17 00:42:03 3: main::readingsBeginUpdate called by ./FHEM/30_MilightBridge.pm (277)
2016.08.17 00:42:03 3: main::MilightBridge_DoPingDone called by (eval 281900) (1)
2016.08.17 00:42:03 3: (eval) called by fhem.pl (1003)
2016.08.17 00:42:03 3: main::AnalyzePerlCommand called by fhem.pl (1021)
2016.08.17 00:42:03 3: main::AnalyzeCommand called by fhem.pl (951)
2016.08.17 00:42:03 3: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (275)
2016.08.17 00:42:03 3: main::telnet_Read called by fhem.pl (3201)
2016.08.17 00:42:03 3: main::CallFn called by fhem.pl (668)
2016.08.17 00:42:03 1: readingsUpdate(,state,unreachable) missed to call readingsBeginUpdate first.
2016.08.17 00:42:13 1: ERROR: empty name in readingsBeginUpdate
2016.08.17 00:42:13 3: stacktrace:
2016.08.17 00:42:13 3: main::readingsBeginUpdate called by ./FHEM/30_MilightBridge.pm (277)
2016.08.17 00:42:13 3: main::MilightBridge_DoPingDone called by (eval 281902) (1)
2016.08.17 00:42:13 3: (eval) called by fhem.pl (1003)
2016.08.17 00:42:13 3: main::AnalyzePerlCommand called by fhem.pl (1021)
2016.08.17 00:42:13 3: main::AnalyzeCommand called by fhem.pl (951)
2016.08.17 00:42:13 3: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (275)
2016.08.17 00:42:13 3: main::telnet_Read called by fhem.pl (3201)
2016.08.17 00:42:13 3: main::CallFn called by fhem.pl (668)
2016.08.17 00:42:13 1: readingsUpdate(,state,unreachable) missed to call readingsBeginUpdate first.
2016.08.17 00:42:23 1: ERROR: empty name in readingsBeginUpdate
2016.08.17 00:42:23 3: stacktrace:
2016.08.17 00:42:23 3: main::readingsBeginUpdate called by ./FHEM/30_MilightBridge.pm (277)
2016.08.17 00:42:23 3: main::MilightBridge_DoPingDone called by (eval 281904) (1)
2016.08.17 00:42:23 3: (eval) called by fhem.pl (1003)
2016.08.17 00:42:23 3: main::AnalyzePerlCommand called by fhem.pl (1021)
2016.08.17 00:42:23 3: main::AnalyzeCommand called by fhem.pl (951)
2016.08.17 00:42:23 3: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (275)
2016.08.17 00:42:23 3: main::telnet_Read called by fhem.pl (3201)
2016.08.17 00:42:23 3: main::CallFn called by fhem.pl (668)
2016.08.17 00:42:23 1: readingsUpdate(,state,unreachable) missed to call readingsBeginUpdate first.
2016.08.17 00:42:33 1: ERROR: empty name in readingsBeginUpdate
2016.08.17 00:42:33 3: stacktrace:
2016.08.17 00:42:33 3: main::readingsBeginUpdate called by ./FHEM/30_MilightBridge.pm (277)
2016.08.17 00:42:33 3: main::MilightBridge_DoPingDone called by (eval 281918) (1)
2016.08.17 00:42:33 3: (eval) called by fhem.pl (1003)
2016.08.17 00:42:33 3: main::AnalyzePerlCommand called by fhem.pl (1021)
2016.08.17 00:42:33 3: main::AnalyzeCommand called by fhem.pl (951)
2016.08.17 00:42:33 3: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (275)
2016.08.17 00:42:33 3: main::telnet_Read called by fhem.pl (3201)
2016.08.17 00:42:33 3: main::CallFn called by fhem.pl (668)
2016.08.17 00:42:33 1: readingsUpdate(,state,unreachable) missed to call readingsBeginUpdate first.
Nach einem Reboot von FHEM scheint das aber wieder weg zu sein. Daher just for your Notice.
Hallo zusammen,
ich hoffe ich darf mich hier mal reinhängen - wenn nicht mache ich ein neues Thema auf.
Habe gestern Abend ein paar Kartons mit LEDs und zubehör geschenkt bekommen und hab gedacht das geht bestimmt auch in FHEM zu integrieren....
Konkret habe ich folgendes:
1x RGB LED-Panel von Kapego
1x "WifiBox 2.0" von Kapego (die sieht absolut genauso aus wie die von Milight nur in schwarz
1x 1-Zonen Fernbedienung von kapego
1x RGB-Kontroller von kapego
Steuern kann ich das ganze über die milight app auf meinem iphone - dort dann eben über den Monitor oben in der Mitte - also der ohne Zonen Auswahl
In fhem habe ich die milightbridge so eingebunden:
define milightbridge1 MilightBridge 192.168.20.113
und bekomme als status "ok"
als milightdevice habe ich:
define testlampe MilightDevice RGB milightbridge1 0
leider will die Lampe über fhem garnichts machen. Da aber die wifi Box ja die milight App funktioniert, sollte ich doch die Lampe von fhem ansprechen können, oder?
Kann mir jemand was dazu sagen?
Vielen Dank!
Gruß
H-Man
Zitat von: h-man-kl am 25 August 2016, 10:14:45
als milightdevice habe ich:
define testlampe MilightDevice RGB milightbridge1 0
Das Problem hatte ich auch mal ich glaube der RGB bereich bzw. RGBW geht ab Slot 5 los.
define testlampe MilightDevice RGB milightbridge1 5 Das sollte gehen insofern die Lampe auf Zone 1 angelernt ist.
Edit: Mehrere Lampen gleichzeitg sprich Master Steuerung geht über die Erzeugung eines weiteren Devices diesmal wird aber Slot A gewählt.
Viel Erfolg :)
erstmal Sanke für die Antwort, hat aber leider nix genutzt bzw. das hatte ich schon probiert.
zum einen gibt fhem dann die Meldung raus, dass der Solt für RGB 0 ist und zum anderen hab ich ja keine Zonen.
Ein Versuch die Lampe einfach mal als RgBW mit den Solts 5 6 7 oder 8 anzulegen hat auch nichts gebracht :-(
Hi Leute, kann man den Discomode auch dimmen? bei mir springt der immer wieder zur letzt eingestellten farbe wenn ich den dimbefehl absetze. Oder hat jemand nen Workaround wie ich den discomode auf brightness 4 laufen lassen kann? möchte den Mode als Lichtspiel im Kinderzimmer laufen lassen wenn die Kids einschlafen sollen. mit der FB geht das wunderbar.
Danke und grüße Wumpe
Hallo, kann ich das irgendwie realisieren das wenn ich z.B zwischen 22 & 6 Uhr das Licht anschalten es im immer im Nacht Modus also gedimmt läuft?
Sonst soll es aber 100% sein.
2. Frage: Kann man irgendwie einstellen das das Licht hoch und runter dimmt wie z.B beim Programm Modus 6 nur ohne flashen?
Danke
Zitat von: Badflex am 05 September 2016, 19:13:40
Hallo, kann ich das irgendwie realisieren das wenn ich z.B zwischen 22 & 6 Uhr das Licht anschalten es im immer im Nacht Modus also gedimmt läuft?
Sonst soll es aber 100% sein.
(($hms gt "09:00" and $hms lt "24:00") and ([Flur_BM:state] eq "motion") and ([?Flur_BM:brightness:d] <37))
((set Flur_Licht_Stripe hsv 0,0,65), set Flur_Licht_Stripe on-for-timer 35)
DOELSEIF
(($hms gt "00:00:01" and $hms lt "08:59:59") and ([Flur_BM:state] eq "motion") and ([?Flur_BM:brightness:d] <37))
((set Flur_Licht_Stripe hsv 46,100,35), set Flur_Licht_Stripe on-for-timer 35)Das nutze ich zum schalten der Milights mit Bewegungsmelder und bestimmter Lichtstärke.
Hier aber auch zu bestimmten Uhrzeiten, entweder Hell oder halt gedimmt und gelbliches Licht für wenn man Nachts aufs wc geht.
Kannste ja entsprechend anpassen wenn es das ist was Du suchst.
Gibt es ein Möglichkeit zu erfahren, ob die Lampe eine Verbindung zur Bridge hat? Ich würde ganz gern den Lampen einfach über den normalen Lichtschalter die Spannung weg nehmen. Möchte dann aber direkt beim starten den neuen Dimmerwert haben. Wie Noxus das hat für Bad und Flur aber über normale Lichtschalter geschaltet.
Tagsüber wenn Spannung an = volle Beleuchtung / Nachts bei Spannung ein = gedimmtes Licht
Jemand eine Idee wie ich das umsetzen kann?
Gibt es eine Möglichkeit sowas wie set LED dimdown night 300 oder dimdown 8 300 zu machen.
Also langsam bis auf night oder einen bestimmten %satz zu dimmen?
Zitat von: Antimaster am 09 September 2016, 13:17:32Tagsüber wenn Spannung an = volle Beleuchtung / Nachts bei Spannung ein = gedimmtes Licht
Jemand eine Idee wie ich das umsetzen kann?
Gar nicht, es wird immer der letzte Zustand geschaltet und du weisst zwischendrin nicht, wann du die Lampe steuern kannst.
Zitat von: Badflex am 12 September 2016, 22:25:39Gibt es eine Möglichkeit sowas wie set LED dimdown night 300 oder dimdown 8 300 zu machen.
Also langsam bis auf night oder einen bestimmten %satz zu dimmen?
night nicht, mit
dim sollte es funktionieren.
ist der LD686 schon in der genialen MilightBridge/Device mit eingepflegt?
Wenn nein kommt das noch?
Ich bekomme es jedenfalls nicht angesprochen.
vg André
Zitat von: ischgucke am 29 September 2016, 23:03:41ist der LD686 schon in der genialen MilightBridge/Device mit eingepflegt?
Wenn nein kommt das noch?
Nicht von mir, sorry. Ich bin auf Hue umgestiegen.
Ist Matt noch hier?
Hi, meine Lampen sind von 2700k bis 6000k einstellbar. Im Modul ist aber ein Bereich von 3000k - 6500k vorgegeben. Sind das nur Zahlenunterschiede oder wird wirklich der Kelvin wert bei mir nun leicht versetzt eingestellt? Wie kann ich den Bereich beeinflussen?
Grüße
Dirk
Mein MiLight CW Controler steht öfters mal einfach auf stat "Error"
Leider sagt das Log mit Verbose5 nicht all zuviel
2016.10.26 17:48:41 4: KuLichtDecke_White_Off: Set OFF; Ramp: 0
2016.10.26 17:48:41 4: KuLichtDecke_White_Dim: Brightness: 9; Ramp: 0; Flags:
2016.10.26 17:48:41 4: KuLichtDecke_CmdQueue_Clear
2016.10.26 17:48:41 5: KuLichtDecke_HSV_Transition: Prepare Start (actual): 0,0,9@1477496921.49958
2016.10.26 17:48:41 4: KuLichtDecke_HSV_Transition: Current: 0,0,9
2016.10.26 17:48:41 4: KuLichtDecke_HSV_Transition: Set: 3000,0,9; Ramp: 0; Flags:
2016.10.26 17:48:41 4: KuLichtDecke_HSV_Transition: Set: 3000,0,9; No Ramp
2016.10.26 17:48:41 4: KuLichtDecke_CmdQueue_Add: h: 3000; s: 0; v: 9; Ctrl ; TargetTime: ; QLen: 1
2016.10.26 17:48:41 5: MilightDevice_HSVToStr: h:3000,s:0,v:9
2016.10.26 17:48:41 4: KuLichtDecke_White_setHSV: ON
2016.10.26 17:48:41 5: KuLichtDecke_CmdQueue_Exec: Next Exec: 1477496921.51922
2016.10.26 17:48:41 4: KuLichtDecke_White_Dim: Brightness: 0; Ramp: 0; Flags: q
2016.10.26 17:48:41 5: KuLichtDecke_HSV_Transition: Prepare Start (cached): 3000,0,9@1477496921.49958
2016.10.26 17:48:41 4: KuLichtDecke_HSV_Transition: Current: 3000,0,9
2016.10.26 17:48:41 4: KuLichtDecke_HSV_Transition: Set: 3000,0,0; Ramp: 0; Flags: q
2016.10.26 17:48:41 4: KuLichtDecke_HSV_Transition: Set: 3000,0,0; No Ramp
2016.10.26 17:48:41 4: KuLichtDecke_CmdQueue_Add: h: 3000; s: 0; v: 0; Ctrl ; TargetTime: ; QLen: 2
2016.10.26 17:48:41 5: MilightDevice_HSVToStr: h:3000,s:0,v:0
2016.10.26 17:48:41 4: KuLichtDecke_White_setHSV: OFF
2016.10.26 17:48:41 5: KuLichtDecke_CmdQueue_Exec: Next Exec: 1477496921.60491
2016.10.26 17:48:41 4: KuLichtDecke_White_On: Set ON: Ramp: 0
2016.10.26 17:48:41 4: KuLichtDecke_White_Dim: Brightness: 9; Ramp: 0; Flags:
2016.10.26 17:48:41 4: KuLichtDecke_CmdQueue_Clear
2016.10.26 17:48:41 5: KuLichtDecke_HSV_Transition: Prepare Start (actual): 0,0,0@1477496921.7437
2016.10.26 17:48:41 4: KuLichtDecke_HSV_Transition: Current: 0,0,0
2016.10.26 17:48:41 4: KuLichtDecke_HSV_Transition: Set: 3000,0,9; Ramp: 0; Flags:
2016.10.26 17:48:41 4: KuLichtDecke_HSV_Transition: Set: 3000,0,9; No Ramp
2016.10.26 17:48:41 4: KuLichtDecke_CmdQueue_Add: h: 3000; s: 0; v: 9; Ctrl ; TargetTime: ; QLen: 1
2016.10.26 17:48:41 5: MilightDevice_HSVToStr: h:3000,s:0,v:9
2016.10.26 17:48:41 4: KuLichtDecke_White_setHSV: Brightness increase from 1 to 1
2016.10.26 17:48:41 5: KuLichtDecke_CmdQueue_Exec: Next Exec: 1477496921.77675
2016.10.26 17:56:54 4: KuLichtDecke_White_Off: Set OFF; Ramp: 0
2016.10.26 17:56:54 4: KuLichtDecke_White_Dim: Brightness: 9; Ramp: 0; Flags:
2016.10.26 17:56:54 4: KuLichtDecke_CmdQueue_Clear
2016.10.26 17:56:54 5: KuLichtDecke_HSV_Transition: Prepare Start (actual): 0,0,9@1477497414.33621
2016.10.26 17:56:54 4: KuLichtDecke_HSV_Transition: Current: 0,0,9
2016.10.26 17:56:54 4: KuLichtDecke_HSV_Transition: Set: 3000,0,9; Ramp: 0; Flags:
2016.10.26 17:56:54 4: KuLichtDecke_HSV_Transition: Set: 3000,0,9; No Ramp
2016.10.26 17:56:54 4: KuLichtDecke_CmdQueue_Add: h: 3000; s: 0; v: 9; Ctrl ; TargetTime: ; QLen: 1
2016.10.26 17:56:54 5: MilightDevice_HSVToStr: h:3000,s:0,v:9
2016.10.26 17:56:54 4: KuLichtDecke_White_setHSV: ON
2016.10.26 17:56:54 5: KuLichtDecke_CmdQueue_Exec: Next Exec: 1477497414.35987
2016.10.26 17:56:54 4: KuLichtDecke_White_Dim: Brightness: 0; Ramp: 0; Flags: q
2016.10.26 17:56:54 5: KuLichtDecke_HSV_Transition: Prepare Start (cached): 3000,0,9@1477497414.33621
2016.10.26 17:56:54 4: KuLichtDecke_HSV_Transition: Current: 3000,0,9
2016.10.26 17:56:54 4: KuLichtDecke_HSV_Transition: Set: 3000,0,0; Ramp: 0; Flags: q
2016.10.26 17:56:54 4: KuLichtDecke_HSV_Transition: Set: 3000,0,0; No Ramp
2016.10.26 17:56:54 4: KuLichtDecke_CmdQueue_Add: h: 3000; s: 0; v: 0; Ctrl ; TargetTime: ; QLen: 2
2016.10.26 17:56:54 5: MilightDevice_HSVToStr: h:3000,s:0,v:0
2016.10.26 17:56:54 4: KuLichtDecke_White_setHSV: OFF
2016.10.26 17:56:54 5: KuLichtDecke_CmdQueue_Exec: Next Exec: 1477497414.39379
state error 2016-10-26 19:21:21
Kann sich jemand vorstellen woher dieses Error kommt? Das Licht reagiert z.b auch nicht mehr auf mein DOIF welches durch einen Bewegungsmelder das Licht auf Night stellt. Ich muss es einschalten und dann ist der state Error weg.
Zitat von: Antimaster am 09 September 2016, 13:17:32
Gibt es ein Möglichkeit zu erfahren, ob die Lampe eine Verbindung zur Bridge hat? Ich würde ganz gern den Lampen einfach über den normalen Lichtschalter die Spannung weg nehmen. Möchte dann aber direkt beim starten den neuen Dimmerwert haben. Wie Noxus das hat für Bad und Flur aber über normale Lichtschalter geschaltet.
Tagsüber wenn Spannung an = volle Beleuchtung / Nachts bei Spannung ein = gedimmtes Licht
Jemand eine Idee wie ich das umsetzen kann?
Ich würde das vermutlich mit einem at-Kommando prüfen alle paar Sekunden oder Minuten ob die Lampe erreichbar ist und wenn ja, dann die aktuelle Zeit prüfen und entsprechend die volle Leistung oder gedimmtes Licht setzen.
Bzgl. der Timeout-"Probleme" (habe ich auch jeden Tag regelmäßig) (...)"Timeout for MilightBridge_DoPing":
Wie ich sehe ist ja in der Funktion "MilightBridge_DoPingStart" der Timeout für den Ping statisch einprogrammiert (https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/30_MilightBridge.pm#L228), zum einen würde es ja vielleicht Sinn machen den Wert dynamisch als Attribut nutzbar zu machen (nur so eine Idee die mir beim drüberschauen gekommen ist :) ) und zum anderen frage ich mich ob man eine bessere Stabilität, Erreichbarkeit erlangen würde wenn ich den Ping-Timeout von 2 höher setze (werde ich mal testen).
Es müsste sich halt mal einer mit entsprechend Sachkenntnis dem Modul annehmen. Da ist ja schon seit Monaten nichts mehr passiert. Habe mit dem TimeOut auch Probleme, dazu steht der Status manchmal falsch da (lampe ist aus, state ist aber night etc) und es gibt auch errors.
Also ich habe nun Mal Heute einen etwas längeren Test gemacht mit verändertem Timeout und ich habe seit 11:30 als ich den Server neu gestartet habe keinen einzigen Timeout mehr beobachtet (hatte den ganzen Tag über die Logdatei offen zur Überwachung). Ich denke - zumindest in meinem Netzwerk - sind 2 Sekunden Timeout einfach zu niedrig, die Bridge "schläft" manchmal ein und braucht einige Sekunden bis sie wieder aufwacht, dann ist der Timeout schon abgelaufen und es gibt diese Fehlermeldung und gesendete Befehle kommen auch nicht mehr an in dem Moment.
Ich habe das ganze nun Mal um ein neues Attribut namens "pingTimeout" erweitert, das Attribut muss einfach dem MiLightBridge hinzugefügt werden wie gewohnt. Dort kann man dann einen Wert (Sekunden) eingeben den man als Timeout verwenden möchte und es sollte so klappen :)
Wenn das Attribut nicht gesetzt ist wird wie gewohnt die 2 Sekunden verwendet.
Hallo MiLight Fhem Fans,
ich habe schon einige Probleme mit Hilfe dieses Forums lösen können und die Bridge V4 + Dimmer laufen alle. Danke dafür.
Nun habe ich gelesen, dass auch einfache Hell/Dunkel (Weiß) Dimmer (FUT021) von der Bridge gesteuert werden können.
http://www.futlight.com/productdetails.aspx?id=125&typeid=146 (http://www.futlight.com/productdetails.aspx?id=125&typeid=146)
Das Anlernen über die Smartphone App (MiLight 2) ist mir auch gelungen und ich kann die LEDs im vollen Umfang steuern.
Doch mit ...
define LED.kueche MilightDevice White MilightBridge1 1
komme ich in Fhem nicht weiter.
Auch mehrere Anlernversuche (volle Helligkeit wie in der App) führten nicht zum Erfolg.
In der MiLight API (http://www.limitlessled.com/dev/ (http://www.limitlessled.com/dev/)) und auch anderswo ist auch mehr von WW WC Dimmern die Rede, als von reinen Brightness-Dimmern.
Wird der Helligkeitsdimmer FUT021 überhaupt von Fhem bzw. dessen Modulen unterstützt?
Über Hilfe/Tipps/Erfahrungen würde ich mich freuen.
Gruß und Danke
Ralf
Hallo Zusammen,
hat jemand mit dem milight bzw. wifilight Modul, geschaft openmilight per UDP zu steuern?
Das openmilight läuft mir und ich kann damit meine Stripes steuern, im lausch Modus, kann ich auch die Signale mit sniffen die ich per Milight Fernbedienung schalte. Das heißt das comipilierte openmilight funktioniert ansich.
Das Modul sagt auch das der connect zu Port 50000 erfolgreich war. Schalten tut sich jedoch nichts!
Ich habe bereits alle Modi versucht V2,3, ohne Erfolg.
Link zum openmilight, das ich nutz.
https://github.com/bakkerr/openmilight_pi
Grüße
Zitat von: lewej am 26 November 2016, 16:23:16
Hallo Zusammen,
hat jemand mit dem milight bzw. wifilight Modul, geschaft openmilight per UDP zu steuern?
Das openmilight läuft mir und ich kann damit meine Stripes steuern, im lausch Modus, kann ich auch die Signale mit sniffen die ich per Milight Fernbedienung schalte. Das heißt das comipilierte openmilight funktioniert ansich.
Das Modul sagt auch das der connect zu Port 50000 erfolgreich war. Schalten tut sich jedoch nichts!
Ich habe bereits alle Modi versucht V2,3, ohne Erfolg.
Link zum openmilight, das ich nutz.
https://github.com/bakkerr/openmilight_pi
Grüße
Hast du auch mal Port 8899 probiert?
Sent from my iPad using Tapatalk
Hallo,
Ich wollte gerade meine RGB- Devices von Milight in den fhem einbinden.
Allerdings bekomme ich beim define des MilightDevice eine Fehlermeldung:
define WZ.Licht MilightDevice RGB MilightDevice 1
Invalid slot: Select 0 for RGB
Über die iOS-App von Milight kann ich die RGB-LED-Stripes aber ansprechen und korrekt steuern.
Angelernt habe ich den Controller in der Zone 1 und in Summe gibt es 4 Zonen.
Anscheinend ist das im Modul nicht vorgesehen, da es im Source-Code fix so steht.
Was kann ich da machen?
Hat sonst noch jemand die RGB-Controller in fhem in Betrieb?
Danke für jeden Hinweis im Voraus
Liebe Grüße
Gerhard
Du bist sicher das du ein altes RGB Device hast? Ich meine nicht das RGB auf dem Controller steht.
Richte es mal als RGBW ab Slot 5 ein.. Siehe FHEMWiki (http://www.fhemwiki.de/wiki/WifiLight#Leuchtmittel)
Hallo,
Ja, da bin ich sicher, weil ich keine RGBW-Strips verbaut habe und mir extra die RGB-Controller gekauft habe.
Aber danke für den Tip mit dem RGBW.
Habe das nun probiert und es funktioniert.
Eigenartig.
Hauptsache es geht.
Lg, Gerhard
Ja und nein - du hast RGB Stripes und Controller, aber die Konfiguration ist RGBW für die aktuellen Geräte. Nur die 'uralten' werden als RGB konfiguriert, das hat mich damals auch sehr verwirrt, daher der Wiki Link mit der Erklärung welche Hardware was ist ;)
Danke für die Erklärung.
Leider funktioniert der Link nicht.
Aber nun ist mir alles klar.
LG, Gerhard
So richtig werde ich noch nicht schlau. Die iBox2 mag mit der FUT038 noch nicht funktionieren. Vielleicht hat jemand noch einen Tipp:
- Milight Controller ans Heim-WLAN angelernt (mit neuer Milight App "Mi-Light")
- In der FritzBox eingestellt, dass die IP nicht neu vergeben werden soll + kein Internetzugriff
- Milight Device mit Smartphone angelernt (Zone 1)
- Mit App lässt sich der RGBW Controller Steuern
Anschließend die fhem.cfg erweitert
define MilightBridge MilightBridge 192.168.0.104
define RGBtest1 MilightDevice RGBW MilightBridge 5
attr RGBtest1 IODev MilightBridge
Steuern lässt sich über fhem aber nichts. Funktionieren App und fhem gleichzeitig? Mh, habe auch schon überlegt, ob man in fhem noch ein pairing durchgeführt werden muss. Gelesen habe ich davon aber noch nichts. Bin ein bisschen ratlos.
Edit:
Mh Frage wohl beantwortet. https://forum.fhem.de/index.php/topic,62114.0.html (https://forum.fhem.de/index.php/topic,62114.0.html)
Hätte man das Forum mal über google stellen sollen ^^
Hey ihr wissenden!
Ich habe eine kurze Frage: wie kann ich in TabletUI bzw einfach in HTML (Button in meiner Index.html) datei der Benutzeroberfläche auf den discomode vom Milight modul zugreifen? ..
Mit einem normalen Ein aus Schalter Icon ("switch") oder müsste ich hier ein anderes Tool verwenden auf der Grafischen oberfläche?
Schalter für ein aus schalten wird ja so definiert:
<li data-row="8" data-col="1" data-sizex="2" data-sizey="2">
<header>Küchenlicht</header>
<div data-type="switch"
data-device="MilightKueche1"
data-get-on="on"
data-get-off="off"
class="cell">
</div>
</li>
ALlerdings nur für ON und OFF wie kann ich nun den discomode hier verwenden und befehle senden ? data-get-discomode ? ;-p keine ahnung leider.
Ich hoffe ihr könnt mir helfen!
LG
Ich hab hier ein Problem mit meinen milights. Habe 3 led Bulbs eine in meiner Stehlampe die funktioniert auch 100%. 2habe ich in meiner Außenbeleuchtung die zusammen geschaltet werden. Ein Halbes Jahr lief auch alles gut. Jetzt musste ich meinen Raspberry neu aufsetzten u d seit dem kann ich die beiden Aussenlampen nicht mehr über Fhem steuern. Über die Fernbedienung Taste 4 geht es aber auf slot 8 in fhem nicht.
Wenn sie über die Bedienung geht sollte das doch auch über die App und fhem gehen ,oder.
Ich bekomm sie auch nicht mehr neu angelernt. Hab schon 1000 mal an und aus geschaltet. Aber sie wollen nicht mehr blinken.
Hat jemand eine idee wie ich das lösen könnte?
bei mir funktioniert leider das ändern des ports nicht, da ich openmilight nutze, benötige ich andere ports, hab es im code selbst geändert, openmilight kann aber bis zu 4 bridges simulieren, daher wäre es schön wenn man das anpassen könnte.
Das funktioniert!
Lege einfach 4 milight bridges mit den entsprechenden Ports an.
Dann die Lampen neu anlernen und gut ist!
Grüße
Matze
hat bei mir nur funtkioniert als ich den port manuell geändert habe in der config datei.
Zitat von: AndreasR81 am 16 Februar 2017, 17:59:27
hat bei mir nur funtkioniert als ich den port manuell geändert habe in der config datei.
Was genau funktioniert nicht? Was hast du im code ändern müssen? Wie sieht das list deines devices aus?
Bei mir funktioniert es, also kann es kein generelles Problem sein.
Sent from my iPad using Tapatalk
Hi,
ich habe seit gestern die beiden Module für Bridge un dDevice im Einsatz. geht gut.
In meinem Logfile tauchen aber sporadisch folgende Messages auf
Use of uninitialized value $devname in hash element at /opt/fhem/FHEM/31_MilightDevice.pm line 2324
Ich habe eine Bridge V3 sowie 3 RGBW Spots
die jeweils mit definieret sind:
define LED1 MighLightDevice RGBW MiLightBridge 5
define LED1 MighLightDevice RGBW MiLightBridge 6
define LED1 MighLightDevice RGBW MiLightBridge 7
Sowie einen Gruppenschalter
define LED1 MighLightDevice RGBW MiLightBridge All
Hallo Zusammen,
ich bin nicht sicher ob meine Frage hier oder im Anfängerbereich richtig aufgehoben ist. Da es aber thematisch zum Milight gehört schreibe ich mal hier.
Ich habe eine Bridge und aktuell 2 RGBW Controller im Einsatz, funktioniert soweit spitze. Leidiglich mit dem Queue Befehl habe ich noch Probleme -> vermutlich liegt es aber auch an der Art wie ich versucht habe meine Idee umzusetzen ;-)
Ich habe mehrere "at" Befehle die zu bestimmten Tageszeiten die Farben ändern sollen.
z.B. (jeweils nur DEF)
*19:00:00 set WZi.Bodenband ondann
*19:00:05 set WZi.Bodenband hsv 222,100,80 q ; set WZi.Bodenband dim 50dann
*19:50:00 set WZi.Bodenband hsv 60,100,100 qJetzt kommt aber im Log:
ZitatPERL WARNING: Argument "q" isn't numeric in numeric gt (>) at ./FHEM/31_MilightDevice.pm line 354.
Ich dachte ich kann die Befehle die ich sende durch Anhängen von "q" in die Queue einhängen, was mache ich falsch? Oder geht das mit der Farbänderung nicht?
Da fehlen noch die Sekunden zwischen dem hsv Wert und dem q. Aber brauchst du denn das q überhaupt? Ich habe das noch nie verwender...
ok! Danke! Das mit den Sekunden probier ich aus... ;-)
hm.. keine Ahnung ob es das zwingend braucht... hat sich in der Beschreibung so gelesen als ob das sinnvoll wäre...
Ok ausprobiert... das q bewirkt:
Mit q wird ein laufender Übergang zu Ende geführt, bevor der neue Übergang (der mit q kommt) ausgeführt wird. Ohne q wird der neue Übergang direkt gestartet
Servus zusammen, muss mich hier nun auch mal mit einbringen! :D
Betreibe seit einigen Monaten mehrere Milights mit GU10 Fassung, an bestehenden Lampen welche über den Unterputz-Schalter bedient werden. Wenn meine MilightBridge über einen längeren Zeitraum von ca. 1ner Std. keine Befehle übermittelt, bekomme ich im Log auch die Meldungen
2017.03.31 12:41:15.116 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 12:57:26.355 1: Timeout for MilightBridge_DoPing reached, terminated process 23786
2017.03.31 12:57:26.355 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:05:06.510 1: Timeout for MilightBridge_DoPing reached, terminated process 24248
2017.03.31 13:05:06.511 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:09:58.579 1: Timeout for MilightBridge_DoPing reached, terminated process 24566
2017.03.31 13:09:58.579 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:54:06.873 1: Timeout for MilightBridge_DoPing reached, terminated process 27218
2017.03.31 13:54:06.874 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:55:23.661 1: Timeout for MilightBridge_DoPing reached, terminated process 27280
2017.03.31 13:55:23.662 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:57:31.879 1: Timeout for MilightBridge_DoPing reached, terminated process 27395
2017.03.31 13:57:31.880 3: BlockingCall for MyMilightBridge1 was abortedüber die hier ja schon seit geraumer Zeit heiß diskutiert wird. Schluss folglich, der vorangehenden Diskusion, schaltet die Bridge ja anscheinend in eine art Ruhe-, Ecomodus und Logt fröhlich vor sich hin!
(Echt kacke!)Kann ich irgendwie verhindern das diese in den Ruhe-, Ecomodus geht? Den der Logeintrag müllt einfach nur den Log zu!
(habe schon überlegt ein notify zu senden wenn die Bridge den status unreachable meldet, um diese am 'leben' zu halten) (evtl. schon jemand einen solchen Workaround versucht!?) Zudem ist mir aber auch folgendes Aufgefallen:Wenn ich die Milight vom Strom nehme
(Wandschalter drücken) und wieder Strom gebe, geht die Milight in den letzten Zustand, wie bereits von Markus M. erwähnt...
Zitat von: Markus M. am 12 September 2016, 22:38:29
Gar nicht, es wird immer der letzte Zustand geschaltet und du weisst zwischendrin nicht, wann du die Lampe steuern kannst.
Wenn ich nun aber die Lampe vom Strom nehme, die Bridge längere Zeit keine Befehle sendet und sich quasi abschaltet und ich
dann die Lampe wieder mit Strom versorge geht diese gedimt, in einer Farbe an die nicht der des letzten Zustandes entspricht!?! ???
Hat, oder kann zufällig jemand das gleiche Verhalten bestätigen/beobachten??
Mich würde nun interessieren mit welchem Parameter oder Vorgehensweise ich diesen Zustand festlegen kann. Also in welchen Zustand die Miligth geht wenn die Bridge einen Timeout hat und ich die Lampe wieder mit Strom versorge! Weiß wäre nice 8), da ich meist beim betreten der Wohnung erstmal ein "normales" Licht
(weiß) benötige, erst im laufe des Abends möchte ich eine bestimmte Licht-Atmosphäre schaffen, was ich dann auch ganz einfach mit FHEM realisieren kann! ;D
Bsp.: Yeelight, habe ich eine im Einsatz,
(leider nur mit einer E27 Fassung erhältlich) welche ich beim einrichten über die App auf weiß eingestellt habe, bevor ich dieser dann den Internetzugang unterbunden habe.
(Musste dies so nachkonfigurieren da ich natürlich bei der ersten Implementierung die Lampe nicht auf weiß eingestellt hatte) ::)
Dann geht diese beim einschalten (Stromkreis geschlossen) auch immer in weiß an! :)
Wenn die Yeelight sich an der Fritzbox anmeldet, wird mit einem notify der connect Befehl gesendet damit ich diese auch gleich wieder aus FHEM heraus steuern kann. Klappt super!
Ist es möglich die Devices der Bridge auf Erreichbarkeit zu prüfen?
(Um bei Erreichbarkeit gleich einen 'set hsv' Befehl auszulösen?) Und da ich ja gerade schon hier bin:
Die Bridge kommuniziert über das UDP Protokoll das keine Quittung liefert, jedoch kann man auch auf TCP umstellen. Welche Vor-, Nachteile hat es auf TCP umzustellen? Bekommt man über TCP eine Quittung ob die Nachricht gesendet oder sogar angekommen ist!? Der 'Device specific help' konnte ich leider keine Vor-, oder Nachteile des TCP Protokolls entnehmen.
Bin schon jetzt gespannt auf eure Antworten! :)
zumindest eines kann ich beantworten:
ZitatIst es möglich die Devices der Bridge auf Erreichbarkeit zu prüfen? (Um bei Erreichbarkeit gleich einen 'set hsv' Befehl auszulösen?)
Und da ich ja gerade schon hier bin:
Die Bridge kommuniziert über das UDP Protokoll das keine Quittung liefert, jedoch kann man auch auf TCP umstellen. Welche Vor-, Nachteile hat es auf TCP umzustellen? Bekommt man über TCP eine Quittung ob die Nachricht gesendet oder sogar angekommen ist!? Der 'Device specific help' konnte ich leider keine Vor-, oder Nachteile des TCP Protokolls entnehmen.
FHEM kommuniziert mit der Bridge über UDP/TCP, die Bridge selbst funkt aber an die Birnen. Die Birnen nehmen stumpf entgegen (sofer sie können - sprich Strom haben). Ein Rückmeldung ist nicht möglich
Zitat von: KernSani am 31 März 2017, 23:18:34
zumindest eines kann ich beantworten:FHEM kommuniziert mit der Bridge über UDP/TCP, die Bridge selbst funkt aber an die Birnen. Die Birnen nehmen stumpf entgegen (sofer sie können - sprich Strom haben). Ein Rückmeldung ist nicht möglich
Ach kacke, somit kann man wirklich auf keine Weiße prüfen ob ein Device gerade verfügbar ist oder nicht! :-\
@KernSani
Die Bridge kann man aber
entweder über UDP oder TCP kommunizieren lassen, liegt zwar beides im OSI-Layer4, sind aber dennoch unterschiedliche Protokolle....
UDP sendet die Daten, ohne sich um den Verbleib zu kümmern und bietet lediglich eine Checksummen-Funktion, und deren Prüfung beim Empfänger. Es wird allerdings bei fehlerhaften Checksummen nichts unternommen - dies bleibt der Applikation überlassen.
TCP stellt sicher, dass der Client die Daten korrekt erhalten hat, und dass sie in der richtigen Reihenfolge ankommen. Dabei geht jedoch einiges an Bandbreite verloren, wodurch die Übertragung verlangsamt wird.
siehe Hier https://glossar.hs-augsburg.de/Unterschiede_zwischen_TCP/UDP (https://glossar.hs-augsburg.de/Unterschiede_zwischen_TCP/UDP)
Ausführlichere Beschreibung der Unterschiede https://www.computerbase.de/forum/showthread.php?t=61320 (https://www.computerbase.de/forum/showthread.php?t=61320)
Im Modul 'MilightBridge' unter 'Device specific help' ist zu lesen:
Zitatprotocol
Default: udp. Change to tcp if you have enabled tcp mode on your bridge.
Aber vielen Dank für die Info mit der Funk-Kommunikation zwischen Bridge und Device, wusste ich nicht!
Mir ist schon klar, dass es einen Unterschied zwischen UDP und TCP gibt ;-) Ich hatte übrigens prototypisch mal eine bridge gebaut, die direkt über USB angesprochen wird: https://forum.fhem.de/index.php/topic,68515.msg599838.html#msg599838
Meine Frage hier ohne das ich jetzt den gesamten Thread durchforsten muss, kann ich mit dem Modul diesen Controller ansteuern, weiß das hier zufällig jemand.
XCSOURCE Magic UFO-WiFi LED-Controller DC12-24 V, LD382
Das funktioniert mit dem Modul WifiLight:
https://wiki.fhem.de/wiki/WifiLight (https://wiki.fhem.de/wiki/WifiLight)
Beste Grüße
Danke... ;)
Servus zusammen, ich schließe mich Stoanze01 an, habe das selbe Problem, mein Log ist richtig zugemüllt mit der MilightBridge.
Ich schalte die Bridge nie aus, sie läuft die ganze zeit durch.
Gibt es vielleicht die Möglichkeit das man den log von der MilightBridge abstellt?
Zitat von: Stoanze01 am 31 März 2017, 23:08:06
Servus zusammen, muss mich hier nun auch mal mit einbringen! :D
Betreibe seit einigen Monaten mehrere Milights mit GU10 Fassung, an bestehenden Lampen welche über den Unterputz-Schalter bedient werden. Wenn meine MilightBridge über einen längeren Zeitraum von ca. 1ner Std. keine Befehle übermittelt, bekomme ich im Log auch die Meldungen
2017.03.31 12:41:15.116 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 12:57:26.355 1: Timeout for MilightBridge_DoPing reached, terminated process 23786
2017.03.31 12:57:26.355 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:05:06.510 1: Timeout for MilightBridge_DoPing reached, terminated process 24248
2017.03.31 13:05:06.511 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:09:58.579 1: Timeout for MilightBridge_DoPing reached, terminated process 24566
2017.03.31 13:09:58.579 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:54:06.873 1: Timeout for MilightBridge_DoPing reached, terminated process 27218
2017.03.31 13:54:06.874 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:55:23.661 1: Timeout for MilightBridge_DoPing reached, terminated process 27280
2017.03.31 13:55:23.662 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:57:31.879 1: Timeout for MilightBridge_DoPing reached, terminated process 27395
2017.03.31 13:57:31.880 3: BlockingCall for MyMilightBridge1 was aborted
über die hier ja schon seit geraumer Zeit heiß diskutiert wird. Schluss folglich, der vorangehenden Diskusion, schaltet die Bridge ja anscheinend in eine art Ruhe-, Ecomodus und Logt fröhlich vor sich hin! (Echt kacke!)
Kann ich irgendwie verhindern das diese in den Ruhe-, Ecomodus geht? Den der Logeintrag müllt einfach nur den Log zu! (habe schon überlegt ein notify zu senden wenn die Bridge den status unreachable meldet, um diese am 'leben' zu halten) (evtl. schon jemand einen solchen Workaround versucht!?)
...
Es ist nicht nur so, dass das log zugemüllt wird, sondern nach meiner Erfahrung wird FHEM tatsächlich immer für eine Denkpause blockiert.
Besser also: anderes Modul nehmen (wifilight); diese Empfehlung ist aber ohne Gewähr, dass das besser ist (wird aber aktiver betreut).
Oder: Bridge(s) gegen eine Eigenbau-Bridge (https://forum.fhem.de/index.php/topic,58742.0.html) tauschen (so hab' ich das gelöst).
Gruß, Beta-User
Stets wenn die "Blocking timeout" Meldungen ins Log wandern gehen die Lampen nicht mehr.
Lässt sich das nicht unterbinden hat keiner eine Idee oder ist keiner Betroffen?
Tja, manchen Leuten kümmern nun mal nicht die Probleme anderer!
Ich habe die Version "30_MilightBridge.pm" vom 24.06.2016 09:07:17 und dann das Modul exclude_from_update gesetzt, warum weiß ich nicht mehr so genau.
Aber ich habe keinerlei Probleme mit dem Modul, alles funktioniert tadellos!
Also, die, die Probleme mit dem Modul haben, einfach mal die Version vom 24.06.2016 ausprobieren!
Danke für den Tipp, das werd ich probieren.
Eine vielleicht etwas abenteuerliche Brechstangen Methode wäre auch einfach die Milight Bridge an eine funktsteckdose zu hängen und per notify aus/an zu schalten. :o
Zitat von: speex am 09 November 2017, 20:03:05
Danke für den Tipp, das werd ich probieren.
Und? :)
Zitat von: Tom111 am 14 November 2017, 15:00:11
Und? :)
Das scheint eh die letzte Version zu sein...
Hab nix neueres gefunden... [emoji848]
Dann bitte mal die Version vom 31.01.2016 - 02:25:17 versuchen.
Hallo,
ich nutze Milight mit meiner V4-Bridge.
Die Slots 5 bis 8 habe ich bereits mit RGBW-Devices belegt. Nun möchte ich noch eine weiße Lampe einbinden. Stehen die Slots dafür die Slots 1 bis 4 zur Verfügung?
Gruß,
André
Hab's gerade probiert. Lampe ist auf Slot 1 angelernt.
Definition in FHEM:
deine Aussenbeleuchtung MilightDevice White MiLightBridge 1
Ich habe mal eine Frage zu MilightDevice:
Ist es eigentlich möglich, über ein Notify eine Farbverlauf zu programmieren?
define sz_Bett_Farbverlauf notify Bett_LED:programm:\sfarbvl\s100 { fhem("set Bett_LED hsv 120,100,60 600 q ;set Bett_LED hsv 240,100,60 600 q ;set Bett_LED hsv 360,100,60 600 q farbvl");}
Bei Wifilight funktioniert das. Bei Milight startet das Programm nicht!
Gestartet wird es mit set Bett_LED hsv 0,100,60 30 q farbvl
Hallo,
Ich habe die Tage FHEM und die rpi geupdatet, seit dem streikt bei mir Milight, ich habe es über openmilight auf dem rpi laufen, openmilight funktioniert auch nach wie vor, nur wenn ich openmilight im debug starte bekomme ich bei jeder anfrage des fhem diese Meldung: Message has invalid size 3 (expecting 8)!, bzw. mehrere hintereinander, die Lampen schalten aber nicht.
Versucht habe ich bereits die bridge und device von Matts Seite sowie einige ältere aus dem FHEM Git, openmilight habe ich auch andere Versionen versucht, ich komme hier nichtmehr weiter, was könnte es noch sein?
Gruß Andreas
einfach mal wieder rausgeholt.
Vielleicht hat jemand einen workaround
Zitat von: TheDestroyer am 29 Juni 2017, 17:07:24
Servus zusammen, ich schließe mich Stoanze01 an, habe das selbe Problem, mein Log ist richtig zugemüllt mit der MilightBridge.
Ich schalte die Bridge nie aus, sie läuft die ganze zeit durch.
Gibt es vielleicht die Möglichkeit das man den log von der MilightBridge abstellt?
Vielleicht kann ja jemand mal die 30_MilightBridge.pm" vom 24.06.2016
hier einstellen
versuch mal "attr MiLight checkInterval 0" einzufügen.
"Milight" natürlich durch den von dir verwendeten Namen der MilightBridge ersetzen!!
Zitat von: Tom111 am 13 Januar 2019, 00:26:45
versuch mal "attr MiLight checkInterval 0" einzufügen.
"Milight" natürlich durch den von dir verwendeten Namen der MilightBridge ersetzen!!
Hallo, das checkInterval funktioniert, nur reagieren irgendwann die Bridges nicht mehr und ich muss FHEM neustarten oder im schlimmsten Fall die Bridges manuell vom Strom nehmen.
Könnte jemand die letzte Version ohne die LogEinträge hier Posten?
Zitat von: hyper2910 am 22 Januar 2019, 08:05:45
Hallo, das checkInterval funktioniert, nur reagieren irgendwann die Bridges nicht mehr und ich muss FHEM neustarten oder im schlimmsten Fall die Bridges manuell vom Strom nehmen.
Könnte jemand die letzte Version ohne die LogEinträge hier Posten?
Hallo,
die aktuellste Version funktioniert bei mir ohne Probleme mit dem besagten Attribut.
Allerdings muss ich sagen, dass die Bridge beim Ausschalten der letzten Lampe die daran hängt, automatisch vom Netz getrennt wird.
Wenn du eine ältere Version haben möchtest (was allerdings dein Problem nicht lösen wird) dann such dir hier eine aus:
https://github.com/mhop/fhem-mirror/commits/master/fhem/FHEM/30_MilightBridge.pm (https://github.com/mhop/fhem-mirror/commits/master/fhem/FHEM/30_MilightBridge.pm)
downloaden, entpacken und 30_MilightBridge.pm sowie 31_MilightDevice.pm austauschen.