Neues Modul: 30_MilightBridge / 31_MilightDevice

speex · 23 Februar 2016, 21:57:45

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...

roman1528 · 23 Februar 2016, 23:40:23

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^^

speex · 24 Februar 2016, 09:51:12

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

blofield · 24 Februar 2016, 13:15:03

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:

Code Auswählen

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

Markus M. · 24 Februar 2016, 20:00:17

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.

blofield · 25 Februar 2016, 12:05:46

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

Hardlife · 29 Februar 2016, 00:34:09

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:

Code Auswählen

##### 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&nbspauf&nbspSchrank
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/

l2r · 01 März 2016, 12:17:40

hi,

hat noch jemand, der Milight-User die Fehlermeldungen aus diesem Thread?

http://forum.fhem.de/index.php/topic,50046.msg417911.html#msg417911

speex · 01 März 2016, 13:01:58

Jau hier auch.

hyper2910 · 01 März 2016, 14:19:38

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.!

mahowi · 01 März 2016, 16:05:58

Beim Start von fhem bekomme ich auch die Meldungen:

Code Auswählen

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:

Code Auswählen

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

Markus M. · 01 März 2016, 19:31:24

FIXED: You need to restart fhem or modify to enable new protocol.

l2r · 02 März 2016, 08:35:56

besten Dank! - läuft

Markus M. · 02 März 2016, 12:46:14

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?

Tom111 · 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:

Hier nur ein Teil der LOG-Einträge:

Code Auswählen

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