[gelöst] MiLight schaltet nicht mehr nach Neuanlage

Begonnen von petjek, 07 Januar 2018, 13:48:26

Vorheriges Thema - Nächstes Thema

petjek

Hallo,

ich hatte dieses Thema schon mal in einem anderen Beitrag geschildert aber da habe ich keine Rückmeldung bekommen. Ein freundliches Forummitglied hatte aber den Tipp, es mal in einem neuen Thread zu probieren, da es ursprünglich um ein anderes Thema ging. Ist also kein Doppelpost, nur eine Korrektur.

Ich habe die Bridge (v4) an einer anderen Steckdose angeschlossen, da sie unnötig weit vom Router weg installiert war und es häufiger zu "Ausfällen" kam, sprich: die Lampen wurden nicht geschaltet.
Nach dem die Bridge wieder hoch gefahren ist, funktionierte erstmal gar nichts mehr. Also habe ich den Nachmittag damit verbracht, eine App zu finden, mit der man auch in halbwegs sicheren WLAN-Netzen (WPA2-PSK) die Bridge wieder mit dem Router verbinden kann. Langer Rede kurzer Sinn: hat dann irgendwann geklappt. Danach alle Lampen über die App "EasyBulb" zurückgesetzt und neu hinzugefügt. Es sind jetzt alle 6 Lampen in der Gruppe "White Bulbs 1" angelernt. Das hatte ich früher nicht, bislang waren die Lampen gar nicht Gruppen zugeordnet, konnten in der App also nur über "All White Bulbs" gesteuert werden.
In FHEM habe ich dann die Bridge neu zu konfiguriert, unter anderem, da sie vom Router eine neue IP bekommen hat und ich vermutet hatte, dass mein Problem etwas damit zu tun haben könnte. Die Bridge hat sich daraufhin brav mit "OK" zurück gemeldet. Nur die Lampen kann ich nicht schalten. Also alles gelöscht und von Vorne begonnen. Aber was ich auch mache, ich bekomme die Lampen nicht angesprochen.

Hier mal die Raw-Definition:

defmod AdF4_MilightBridge MilightBridge 192.168.0.115
attr AdF4_MilightBridge checkInterval 10
attr AdF4_MilightBridge event-on-change-reading state
attr AdF4_MilightBridge protocol udp
attr AdF4_MilightBridge room CUL
attr AdF4_MilightBridge sendInterval 100

setstate AdF4_MilightBridge ok
setstate AdF4_MilightBridge 2018-01-03 21:24:31 sendFail 0
setstate AdF4_MilightBridge 2018-01-03 20:50:03 slot0
setstate AdF4_MilightBridge 2018-01-03 20:50:03 slot1
setstate AdF4_MilightBridge 2018-01-03 20:50:03 slot2
setstate AdF4_MilightBridge 2018-01-03 20:50:03 slot3
setstate AdF4_MilightBridge 2018-01-03 20:50:03 slot4
setstate AdF4_MilightBridge 2018-01-03 20:50:03 slot5
setstate AdF4_MilightBridge 2018-01-03 20:50:03 slot6
setstate AdF4_MilightBridge 2018-01-03 20:50:03 slot7
setstate AdF4_MilightBridge 2018-01-03 20:50:03 slot8
setstate AdF4_MilightBridge 2018-01-03 21:24:31 state ok


defmod WZ_Deckenlampe MilightDevice White AdF4_MilightBridge A
attr WZ_Deckenlampe IODev AdF4_MilightBridge
attr WZ_Deckenlampe devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
attr WZ_Deckenlampe event-on-change-reading state,transitionInProgress
attr WZ_Deckenlampe group Licht
attr WZ_Deckenlampe lightSceneParamsToSave brightness
attr WZ_Deckenlampe restoreAtStart 0
attr WZ_Deckenlampe room Wohnzimmer
attr WZ_Deckenlampe updateGroupDevices 1
attr WZ_Deckenlampe verbose 5
attr WZ_Deckenlampe webCmd on:off:dim:ct

setstate WZ_Deckenlampe off
setstate WZ_Deckenlampe 2018-01-03 21:23:10 brightness 0
setstate WZ_Deckenlampe 2018-01-03 21:23:10 brightness_on 36
setstate WZ_Deckenlampe 2018-01-03 21:23:10 ct 3000
setstate WZ_Deckenlampe 2018-01-03 21:23:10 hsv 3000,0,0
setstate WZ_Deckenlampe 2018-01-03 21:23:10 state off
setstate WZ_Deckenlampe 2018-01-03 21:23:10 transitionInProgress 0


Verbose ist auf 5 bei Bridge und Device

2018-01-03 21:26:39 MilightDevice WZ_Deckenlampe transitionInProgress: 1
2018-01-03 21:26:39 MilightDevice WZ_Deckenlampe on 36
2018-01-03 21:26:39 MilightDevice WZ_Deckenlampe transitionInProgress: 0
2018-01-03 21:26:41 MilightDevice WZ_Deckenlampe transitionInProgress: 1
2018-01-03 21:26:41 MilightDevice WZ_Deckenlampe on 9
2018-01-03 21:26:41 MilightDevice WZ_Deckenlampe off
2018-01-03 21:26:41 MilightDevice WZ_Deckenlampe transitionInProgress: 0


Kann mir jemand helfen? Ich habe keine Ahnung wo ich nachsehen muss, nachdem ich die Commandref und Wiki durch habe. Wobei das Wiki nicht wirklich ergiebig ist was das angeht.
An der Slot-Zuordnung liegt es nicht, ich habe gerade alle Slots für weiße Lampen ausprobiert (1..4, A hatte ich ja schon)
Daher sieht das jetzt so aus:

defmod AdF4_MilightBridge MilightBridge 192.168.0.115
attr AdF4_MilightBridge checkInterval 10
attr AdF4_MilightBridge event-on-change-reading state
attr AdF4_MilightBridge protocol udp
attr AdF4_MilightBridge room CUL
attr AdF4_MilightBridge sendInterval 100
attr AdF4_MilightBridge verbose 5

setstate AdF4_MilightBridge ok
setstate AdF4_MilightBridge 2018-01-07 13:47:17 sendFail 0
setstate AdF4_MilightBridge 2018-01-07 09:09:43 slot0
setstate AdF4_MilightBridge 2018-01-07 09:09:43 slot1 WZ_Deckenlampe
setstate AdF4_MilightBridge 2018-01-07 09:09:43 slot2 WZ_Deckenlampe
setstate AdF4_MilightBridge 2018-01-07 09:09:43 slot3 WZ_Deckenlampe
setstate AdF4_MilightBridge 2018-01-07 09:09:43 slot4 WZ_Deckenlampe
setstate AdF4_MilightBridge 2018-01-07 09:09:43 slot5
setstate AdF4_MilightBridge 2018-01-07 09:09:43 slot6
setstate AdF4_MilightBridge 2018-01-07 09:09:43 slot7
setstate AdF4_MilightBridge 2018-01-07 09:09:43 slot8
setstate AdF4_MilightBridge 2018-01-07 13:47:17 state ok


Jemand?

LG,
Arne
Die Möglichkeiten der deutschen Grammatik können einen, wenn man sich darauf, was man ruhig, wenn man möchte, sollte, einlässt, überraschen.

petjek

Hat das echt noch keiner gehabt? Oder eine Idee woran das liegen kann?
Interessant finde ich, dass ich über ,,get ... hsv (bzw. rgb) Werte angezeigt bekomme. Daher würde ich sagen, dass die Kommunikation mit der Bridge soweit funktioniert. Und da sich die Lampen mit der App problemlos schalten lassen scheint die ja auch mit der Lampen zu sprechen.


Gesendet von iPhone mit Tapatalk
Die Möglichkeiten der deutschen Grammatik können einen, wenn man sich darauf, was man ruhig, wenn man möchte, sollte, einlässt, überraschen.

Beta-User

Das klingt insgesamt danach, als sei die Kommunikation zwischen FEHM und der Bridge gestört. Da die Kommunikation eigentlich nicht bidirektional ist, glaube ich nicht, dass der "get"-Befehl tatsächlich ein Indiz dafür ist, dass das reibungslos klappt (Quellcode-Analyse wäre zur Verifizierung angesagt).

Komisch ist, dass die Bridge ihre Einstellungen vergessen hatte - das ist kein normales Verhalten. Wenn sich die Lampen aber wirklich weiter über die App schalten lassen, könnte es eigentlich nur sein, dass die App die Kommunikation auf TCP umgeschaltet hat. Das könntest du ggf. noch testen.

Ansonsten würde ich
a) Wifilight zur Ansteuerung nehmen (das blockt nicht so - perfmon und apptime würden das ggf. zeigen)
b) die brigde nochmal resetten und dann _nur_ von FHEM aus versuchen zu schalten (also ohne die APP).

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

petjek

OMG, ist das peinlich. Ich habe den Fehler gefunden. Und der saß wie so häufig vor dem Monitor.
Ich hatte beim Anlegen die IP-Adressen vertausch. Und da die "falsche" Adresse die von einem LD382 war, habe ich natürlich auch einen Status "ok" zurück bekommen.  ::)
Blutiger Anfängerfehler, ganz blutiger Anfängerfehler...

LG,
Arne
Die Möglichkeiten der deutschen Grammatik können einen, wenn man sich darauf, was man ruhig, wenn man möchte, sollte, einlässt, überraschen.