Hi zusammen,
mein kleines Bastelprojekt am Wochenende war die Abschaffung der Milight-Bridge... Dazu gibt es schon ein paar Lösungen, soweit ich das gesehen habe, aber keine, die ohne WLAN auskommt, daher möchte ich meine Lösung kurz vorstellen. Eines vorab: Das Ganze ist noch im Beta-Stadium, sicherlich noch nicht 100%ig stabil und Coding-technisch eher fragwürdig ;-)
Die Idee in Kurzform: Arduino Nano mit openmili (nRF24L01) hängt direkt am USB des FHEM-Raspi - Milights werden über den USB direkt angesteuert.
Schritt 1: Arduino Nano und Funkmodul (z.B. nRF024L01) zusammen stecken hier (http://"http://schullebernd.de/arduino_und_nrf24l01_verbinden/") ist das ganz schön beschrieben.
Schritt 2: Den openMili Sketch (https://github.com/henryk/openmili) auf dem Nano zum Laufen bringen.
Schritt 3: ID deiner Milights-Fernbedienung sniffen (Details dazu z.B. hier (http://torsten-traenkner.de/wissen/smarthome/openmilight.php))
Schritt 4: Im openmili Sketch anpassen, damit der Nano beim Start auf Senden eingestellt ist:
static bool receiving = false;
Schritt 5: Angehängtes Modul ins FHEM Verzeichnis packen (und reload)
Schritt 6: openMiliBridge Device anlegen (passenden USB port eintragen, der letzte Parameter ist der open gesniffte ID Code der Fernbedienung)
define openMili openMiliBridge /dev/ttyUSB3@115200 B81234
Schritt 7: IODevice der Milight Devices anpassen, als Beispiel:
attr myMilight IODev openMili
Schritt 8: Milights über USB schalten und Bridge wegwerfen...
Wie gesagt, das Ganze ist noch eher experimentell und ob es tatsächlich besser funktioniert, als die Milight Bridge wird sich zeigen müssen...
ToDo: Modul-Coding überarbeiten - habe nur irgendwie eine USB-Ausgabe in die 30_MilightBridge.pm reingefummelt.
Über Feedback / Empfehlungen freue ich mich natürlich...
Grüße,
Oli
Edit 06.03.
* bessere Behandlung des USB Devices (insbesondere bei disconnect/reconnect)
* Set Befehle für disconnect/connect
* Vom Nano zurückgelieferte Daten werden geloggt (Level 4)
* Beschreibung (Schritt 7) angepasst um Reihenfolge-Probleme in fhem.cfg zu vermeiden.
Hallo KernSani,
das klingt interessant.
Ich besitzte jedoch nur das MiLight Modul "Wireless WiFi Steuermodul LED-Controller Wlan 2.4G RGBW".
Das heißt, ich habe keine Fernbedienung dazu.
Gibt es hierzu auch eine Lösung?
VG, Thomas
Zitat von: ToM_ToM am 27 April 2017, 12:53:07
Gibt es hierzu auch eine Lösung?
Du kannst dann entweder die ID Deines WLAN-Controllers sniffen (was mir am naheliegendsten erscheint) oder auch willkürlich eine ID festlegen (6-stellige HEX), mußt dann aber noch pairen, also gleich nach power-on der Leuchtmittel einen Befehl absetzen. Ist wohl beliebig, am besten ist aber nach meiner Erfahrung weiß, volle Leuchtstärke ohne ramp.
@KernSani:
Klasse Sache, werde ich bei Gelegenheit mal ausprobieren und hätte dann WLAN aus meiner FHEM-Installation vollends verbannt :).
Wie ich das verstanden habe, gibt es bei diesem Ansatz pro FB-Kanal je ein IO-Modul-define, hat man also 16 Leuchtmittelgruppen, braucht man 2x16 defines (jeweils Milight-Bridge+Milight-Device)?
Hast Du schon Ideen, wie man den output aus den FB-Empfängen weiter verarbeiten könnte? Die FB-ID als userattr bei den Milight-Devices hinterlegen, bei Empfang auswerten, welche Devices das als attr. hinterlegt hatten und dann den Status mit setreading (?) anpassen? Dafür müßte man doch eigentlich "nur noch" aus dem Sendecode den richtigen Status rückrechnen. Das dürfte aber kein Problem sein. Oder doch, weil es dann im obigen 16-er Beispiel auch viele Devices wären, die den USB-Code verarbeiten wollen? ...könnte man ggf. aber auch mit einem "Ist Empfangs-Master-Device-Attribut" umgehen.?
Mal schaun'...
Gruß, Beta-User
Hallo KernSani,
dein Vorschlag hat gut funktioniert. Habe mich dann aber aus Kompatibilitätsgründen dafür entschieden:
https://servernetworktech.com/2014/09/limitlessled-wifi-bridge-4-0-conversion-raspberry-pi/
Voraussetzung eine original Milight Bridge und ein wenig Lötkenntnisse.
Grüsse Jürgen
Zitat von: ToM_ToM am 27 April 2017, 12:53:07
Ich besitzte jedoch nur das MiLight Modul "Wireless WiFi Steuermodul LED-Controller Wlan 2.4G RGBW".
Das heißt, ich habe keine Fernbedienung dazu.
Gibt es hierzu auch eine Lösung?
Wenn die Birnen auf die selben Codes hören, wie bei der "normalen" Milight Bridge, sollte das so funktionieren, wie Beta-User sagt.
Zitat von: Beta-User am 27 April 2017, 14:11:16
Wie ich das verstanden habe, gibt es bei diesem Ansatz pro FB-Kanal je ein IO-Modul-define, hat man also 16 Leuchtmittelgruppen, braucht man 2x16 defines (jeweils Milight-Bridge+Milight-Device)?
Beim oben dargestelltem Ansatz muss nur das Bridge Device definiert werden und das IODev-Attribut in den bestehenden Milight-Devices geändert werden. Aktuell wird bei "meiner" openmili-Bridge die ID in der DEF mitgegegeben, d.h. pro Bridge eine ID. Ich könnte mir aber vorstellen, dass man das erweitert, so dass ein Device mehrere IDs bedienen kann (das würde aber vermutlich eine Anpassung im MILIGHT_DEVICE Modul erfordern). Alternativ müsste es theoretisch funktionieren mehrere openmili-Bridge devices auf den selben physischen Nano zu legen, das habe ich aber nicht getestet.
[/quote]
Zitat
Hast Du schon Ideen, wie man den output aus den FB-Empfängen weiter verarbeiten könnte? Die FB-ID als userattr bei den Milight-Devices hinterlegen, bei Empfang auswerten, welche Devices das als attr. hinterlegt hatten und dann den Status mit setreading (?) anpassen? Dafür müßte man doch eigentlich "nur noch" aus dem Sendecode den richtigen Status rückrechnen. Das dürfte aber kein Problem sein. Oder doch, weil es dann im obigen 16-er Beispiel auch viele Devices wären, die den USB-Code verarbeiten wollen? ...könnte man ggf. aber auch mit einem "Ist Empfangs-Master-Device-Attribut" umgehen.?
darüber habe ich mir noch nicht wirklich Gedanken gemacht, da ich meine FB nicht benutze... Das sollte aber auch über das Bridge-Device steuerbar sein...
Das Projekt liegt bei mir aktuell ein bisschen auf Eis, da ich a) die Nanos für mySensors-Nodes gebraucht habe und b) ich mit der Funkleistung der RF024Ns (ohne Antenne) nicht zufrieden war. Die nächste Lieferung aus China lässt auf sich warten, ich will aber am Wochenende mal versuchen meinem mySensors Gateway openmili beizubringen... Wenn das klappt, kann's weiter gehen
Grüße,
Oli
Zitat von: KernSani am 29 April 2017, 00:04:08
Beim oben dargestelltem Ansatz muss nur das Bridge Device definiert werden und das IODev-Attribut in den bestehenden Milight-Devices geändert werden. Aktuell wird bei "meiner" openmili-Bridge die ID in der DEF mitgegegeben, d.h. pro Bridge eine ID.
OK, das bedeutet, die Kanalinfo (letztes Byte des zu sendenden Befehls) wird wie üblich generiert, für 16 Kanäle wären das also 4 Bridge-Defines wie bisher. Danke für die Erläuterung.
Zitat
Ich könnte mir aber vorstellen, dass man das erweitert, so dass ein Device mehrere IDs bedienen kann (das würde aber vermutlich eine Anpassung im MILIGHT_DEVICE Modul erfordern).
Das dachte ich auch erst. Habe mir den Quellcode von Milight_device noch nicht unter dem Gesichtspunkt näher angesehen, aber vielleicht könnte man mehr virtuelle Kanäle als sonst üblich definieren und dann die zugehörigen weiteren FB-ID's als Attribute bei der Bridge speichern?
Also: 1. ID aus dem Define wie bisher,
2. ID etc... bei Ansteuerung von Kanal 10-19 (?) bzw. 20-29 (?)
Muß ich mir bei Gelegenheit mal ansehen, ob Milight_device tollerant für sowas wäre...
Mehrere logische Devices auf ein physisches IO zu legen sollte gehen, werde das testen, habe noch ein WCH-Nano-MySensors-GW mit "großem" Modul hier rumliegen.
Aber auch bei mir eilt das alles nicht, viel Spaß beim Testen!
Gruß, Beta-User
Hi,
hat jemand eine Idee ich konnte alles wie berschrieben ausführen, allerdings schaltet der nano Transmitter nichts, resp. den Controller nicht.
Ich sehe dass er verbunden ist und per SerialMonitor sehe ich auch das er etwas empfängt.
Log vom Empfangen und Senden:
2017.07.09 21:52:23 4 : openMili_Read: B0 D6 40 70 C1 03 68
2017.07.09 21:52:23 4 : openMili_Read: .
2017.07.09 21:52:23 4 : openMili_Read: .
2017.07.09 21:52:23 4 : openMili_Read: .
2017.07.09 21:52:23 4 : openMili_Read: .
2017.07.09 21:52:23 4 : openMili_Read: .
2017.07.09 21:52:23 4 : openMili_Read: .
2017.07.09 21:52:23 4 : openMili_Read: .
2017-07-09 21:52:27 MilightDevice Test_LED_Stripes transitionInProgress: 1
2017.07.09 21:52:27 4 : openMili_Write: Command: 45 00 552017.07.09 21:52:27 4 : openMili_Write: Command found: 32017.07.09 21:52:27 4 : openMili_Write: USBCommand: B0D6400000033C 2017.07.09 21:52:27 4 : openMili_Write: Command: 4E 1A 552017.07.09 21:52:27 4 : openMili_Write: Brightness: 1A..192 - C02017.07.09 21:52:27 4 : openMili_Write: USBCommand: B0D64000C00E3D 2017.07.09 21:52:27 4 : openMili_Write: Command: 40 B0 552017.07.09 21:52:27 4 : openMili_Write: USBCommand: B0D64018000F3E 2017.07.09 21:52:27 4 : openMili_Write: Command: 45 00 552017.07.09 21:52:27 4 : openMili_Write: Command found: 32017.07.09 21:52:27 4 : openMili_Write: USBCommand: B0D6400000033F 2017.07.09 21:52:27 4 : openMili_Write: Command: 4E 1A 552017.07.09 21:52:27 4 : openMili_Write: Brightness: 1A..192 - C02017.07.09 21:52:27 4 : openMili_Write: USBCommand: B0D64000C00E40 2017.07.09 21:52:27 4 : openMili_Write: Command: 40 B0 552017.07.09 21:52:27 4 : openMili_Write: USBCommand: B0D64018000F41 2017-07-09 21:52:27 MilightDevice Test_LED_Stripes transitionInProgress: 0
Gruss
hat sich gelöst, der Scatch hatte einen Fehler :)
Hallo,
mir gefällt auch der Ansatz ohne Wlan, darum versuch ich mich gerade daran. Eine Original Milight-Bridge mit einem RGBW-Bulb nutz ich schon länger mit den Modulen MilightbBridge und MilightDevice. Eine FB hab ich nicht.
Das Kompilieren und flashen hab ich jetzt hinbekommen. Was noch nicht klappt ist das schalten.
Eingebunden ist die Bridge, mit:
define openMili openMiliBridge /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02MHZO-if00-port0@115200 B81234 Internals:
CFGFN
Clients :MilightDevice:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02MHZO-if00-port0@115200 B81234
DEVID B81234
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02MHZO-if00-port0@115200
FD 82
INTERVAL 100
NAME openMili
NR 596
NTFY_ORDER 50-openMili
PARTIAL
SENDFAIL 0
STATE ok
TYPE openMiliBridge
cmdCnt 220
cmdLastSent 1506507352.61415
cmdQueueLock 0
0:
1:
2:
3:
4:
5:
NAME Mi_Wecklicht
6:
NAME mialight
7:
8:
MatchList:
1:MilightDevice .*
READINGS:
2017-09-27 11:21:58 slot0
2017-09-27 11:21:58 slot1
2017-09-27 11:21:58 slot2
2017-09-27 11:21:58 slot3
2017-09-27 11:21:58 slot4
2017-09-27 11:21:58 slot5 Mi_Wecklicht
2017-09-27 11:21:58 slot6 mialight
2017-09-27 11:21:58 slot7
2017-09-27 11:21:58 slot8
2017-09-27 12:09:35 state ok
cmdQueue:
Attributes:
event-on-change-reading state
room CUL
sendInterval 100
verbose 4 Für mich sieht das mit diesem Status gut aus.
Die Definition des bereits vorhandenen MilightDevice
Define mi_Wecklicht2 MilightDevice RGBW MiLightBridge 5hab ich geändert in
Define mi_Wecklicht2 MilightDevice RGBW openMili 5welches nun so aussieht
Internals:
DEF RGBW openMili 5
INIT 1
IODev openMili
LEDTYPE RGBW
NAME Mi_Wecklicht
NR 171
NTFY_ORDER 50-Mi_Wecklicht
SLOT 5
SLOTID 5
STATE off
TYPE MilightDevice
READINGS:
2017-09-27 12:15:52 brightness 0
2017-09-27 12:13:41 brightness_on 100
2017-09-27 12:15:52 discoMode 0
2017-09-27 12:15:52 discoSpeed 0
2017-09-27 12:15:52 hsv 0,0,0
2017-09-27 12:15:52 hue 0
2017-09-27 12:13:41 previousState 0,0,100
2017-09-27 12:15:52 rgb 000000
2017-09-27 12:15:52 saturation 0
2017-09-27 12:15:52 state off
2017-09-27 12:15:52 transitionInProgress 0
helper:
COMMANDSET on off toggle dimup dimdown discoModeUp:noArg discoSpeedUp:noArg discoSpeedDown:noArg night:noArg white:noArg toggleWhite:noArg pair unpair restorePreviousState:noArg saveState:noArg restoreState:noArg hsv rgb:colorpicker,RGB hue:colorpicker,HUE,0,1,360 saturation:slider,0,100,100 preset dim:slider,0,4,100 brightness:slider,0,4,100
colorLevel 0
colorValue 176
targetHue 0
targetSat 0
targetTime 1506507352.44138
targetVal 0
whiteLevel 0
COLORMAP:
176
175
175
174
174
173
173
172
172
171
171
170
170
169
169
168
167
167
166
166
165
165
164
164
163
163
162
162
161
161
160
159
159
158
158
157
157
156
156
155
155
154
154
153
153
152
151
151
150
150
149
149
148
148
147
147
146
146
145
145
144
143
142
142
141
140
139
138
138
137
136
135
134
134
133
132
131
130
130
129
128
127
126
126
125
124
123
122
122
121
120
119
118
118
117
116
115
114
114
113
112
111
110
110
109
108
107
106
106
105
104
103
102
102
101
100
99
98
98
97
96
95
95
94
93
93
92
91
91
90
89
89
88
87
87
86
85
85
84
83
83
82
81
81
80
79
79
78
77
77
76
75
75
74
73
73
72
71
71
70
69
69
68
67
67
66
65
65
64
63
63
62
61
61
60
59
59
58
57
57
56
55
55
54
53
53
52
51
51
50
49
49
48
47
47
46
45
45
44
43
43
42
41
41
40
39
39
38
37
37
36
35
35
34
33
33
32
31
31
30
29
29
28
27
27
26
25
25
24
23
23
22
21
21
20
19
19
18
17
17
17
16
15
15
14
13
12
11
11
10
9
8
7
7
6
5
4
3
3
2
1
0
254
254
253
252
251
250
250
249
248
247
246
246
245
244
243
242
242
241
240
239
238
238
237
236
235
234
234
233
232
231
230
230
229
228
227
226
226
225
224
223
222
222
221
220
219
218
218
217
216
215
214
214
213
212
211
210
210
209
208
207
206
206
205
204
203
202
202
201
200
199
198
198
197
196
195
194
194
193
192
191
190
190
189
188
187
186
186
185
184
183
182
182
181
180
179
178
178
177
GAMMAMAP:
0
4
4
4
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
cmdQueue:
Attributes:
IODev openMili
alexaName neptun
devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
event-on-change-reading state,transitionInProgress
genericDeviceType light
lightSceneParamsToSave hsv
restoreAtStart 1
room Alexacontrol,Homekit,Wohnzimmer
userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 room_map structexclude
webCmd on:off:dim:hue:night:white:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffff00:rgb C1C18C1Nach meinem Verständnis sollte es nun möglich sein die Lampe zu schalten, ohne erneutes pairen. Geht aber nicht. Da ich hier zwei nRF24L01 Module habe, hab ich auch schonmal getauscht. Auch Versuche ein neu angelegtes MilightDevice mit einem neuen, noch ungepairten RGBW-BULB scheitern. Die Entfernung liegt zum testen bei etwa 1m.
Wie muss/kann ich nun vorgehen um den Fehler zu finden ?
Beim ausführen des on-Befehls steht, mit verbose 4 bei der openmili Bridge, folgendes im Logfile:
Zitat2017.09.27 21:48:33 4: openMili_Write: Command: 45 00 55
2017.09.27 21:48:33 4: openMili_Write: Command found: 3
2017.09.27 21:48:33 4: openMili_Write: USBCommand: B81234000003BB
2017.09.27 21:48:33 4: openMili_Write: Command: 4E 1A 55
2017.09.27 21:48:33 4: openMili_Write: Brightness: 1A..192 - C0
2017.09.27 21:48:33 4: openMili_Write: USBCommand: B8123400C00EBC
2017.09.27 21:48:33 4: openMili_Write: Command: 40 9B 55
2017.09.27 21:48:33 4: openMili_Write: USBCommand: B812342D000FBD
2017.09.27 21:48:33 4: openMili_Write: Command: 45 00 55
2017.09.27 21:48:33 4: openMili_Write: Command found: 3
2017.09.27 21:48:33 4: openMili_Write: USBCommand: B81234000003BE
2017.09.27 21:48:33 4: openMili_Write: Command: 4E 1A 55
2017.09.27 21:48:33 4: openMili_Write: Brightness: 1A..192 - C0
2017.09.27 21:48:33 4: openMili_Write: USBCommand: B8123400C00EBF
2017.09.27 21:48:33 4: openMili_Write: Command: 40 9B 55
2017.09.27 21:48:33 4: openMili_Write: USBCommand: B812342D000FC0
Hallo,
hat sich wie beim Vorgänger nach intensiverem beschäftigen geklärt, es geht nun.
Das Problem ist jetzt das gleiche welches Kernsani hier hattte:
https://forum.fhem.de/index.php?topic=68370.0 (https://forum.fhem.de/index.php?topic=68370.0)
Zitat==> Wenn ich ein "off" sende, wird die Birne (ich verwende RGBWs) runter gedimmt, aber nicht ausgeschaltet...
Allerdings ist die Bridge mit der Device ID beginnend mit B8xxxx angegeben !
Sind andere ID's auch möglich ? bspw. B7xxxx oder B5xxxx
Ist bei anderer ID ein unpair nötig ?
Wie und wo kann ich die Rampe im Modul mal auf 0 stellen ?
Hat jemand nen Ratschlag was man noch versuchen könnte ?
Moin,
ich bin von dem Projekt auch sehr begeistert !!!
Da ich mich schon länger mit den Bridges rumärgere;
iBox1 [die kleine Lampe mit integrierter Brdige, die mal ging aber nun nicht mehr will] und
iBox2 [die kleine Kiste mit dem weissen Label, die nicht aus FHEM geht])
wäre das eine sehr willkommene Ablösung.
Via Smartphone geht das ja schön und gut, aber ich würde das auch gerne vom Fhem Tablet aus steuern können.
Dann hab ich mir also mal den "Nano-openMili-ohne-WLAN" zusammen gelötet und an meinen Fhem Testsystem (Raspberry Pi Zero W) gehängt.
Soweit alles gut. Sketch kompiliert (CE/CSN PINs vorher auf 6/7 geändert) und erfolgreich geflasht.
Bridge in Fhem eingebunden und ist auf Status OK.
Internals:
CFGFN
Clients :MilightDevice:
DEF /dev/serial/by-path/platform-20980000.usb-usb-0:1:1.0-port0@115200 B81234
DEVID B81234
DeviceName /dev/serial/by-path/platform-20980000.usb-usb-0:1:1.0-port0@115200
FD 8
INTERVAL 100
NAME openMiLiBridge
NR 32
NTFY_ORDER 50-openMiLiBridge
PARTIAL
SENDFAIL 0
STATE ok
TYPE openMiliBridge
cmdCnt 188
cmdLastSent 1507930704.70232
cmdQueueLock 0
0:
1:
2:
3:
4:
5:
NAME MiLightBridge.Lampe.Zone1
6:
7:
8:
MatchList:
1:MilightDevice .*
READINGS:
2017-10-13 23:24:11 slot0
2017-10-13 23:24:11 slot1
2017-10-13 23:24:11 slot2
2017-10-13 23:24:11 slot3
2017-10-13 23:24:11 slot4
2017-10-13 23:24:11 slot5 MiLightBridge.Lampe.Zone1
2017-10-13 23:24:11 slot6
2017-10-13 23:24:11 slot7
2017-10-13 23:24:11 slot8
2017-10-13 23:27:26 state ok
cmdQueue:
Attributes:
event-on-change-reading state
sendInterval 100
verbose 4
MiLight Device auf die neue Bridge geschoben:
Internals:
CFGFN
DEF RGBW openMiLiBridge 5
INIT 1
IODev openMiLiBridge
LEDTYPE RGBW
NAME MiLightBridge.Lampe.Zone1
NR 15
NTFY_ORDER 50-MiLightBridge.Lampe.Zone1
SLOT 5
SLOTID 5
STATE off
TYPE MilightDevice
READINGS:
2017-10-13 23:38:23 brightness 0
2017-10-13 23:38:23 brightness_on 44
2017-10-13 23:38:23 discoMode 0
2017-10-13 23:38:23 discoSpeed 0
2017-10-13 23:38:23 hsv 228,100,0
2017-10-13 23:38:23 hue 228
2017-10-13 23:38:23 previousState 228,100,44
2017-10-13 23:38:23 rgb 000000
2017-10-13 23:38:23 saturation 100
2017-10-13 23:38:23 state off
2017-10-13 23:38:23 transitionInProgress 0
helper:
COMMANDSET on off toggle dimup dimdown discoModeUp:noArg discoSpeedUp:noArg discoSpeedDown:noArg night:noArg white:noArg toggleWhite:noArg pair unpair restorePreviousState:noArg saveState:noArg restoreState:noArg hsv rgb:colorpicker,RGB hue:colorpicker,HUE,0,1,360 saturation:slider,0,100,100 preset dim:slider,0,4,100 brightness:slider,0,4,100
colorLevel 0
colorValue 24
targetHue 228
targetSat 100
targetTime 1507930703.87545
targetVal 0
whiteLevel 0
COLORMAP:
176
[i] (das hab ich gekürzt 175-1) [/i]
0
254
[i] (das hab ich gekürzt 253-178) [/i]
177
GAMMAMAP:
0
4
4
4
4
5
6
[i](das hab ich gekürzt 7-99) [/i]
100
cmdQueue:
Attributes:
IODev openMiLiBridge
devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
event-on-change-reading state,transitionInProgress
lightSceneParamsToSave hsv
restoreAtStart 1
verbose 4
webCmd on:off:dim:hue:night:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffff00
Aber es geht genau nix.
Leider hab ich keine Fernbedienung die ich auslesen könnte.
Wenn ich eine (Mi)Lampe mit Strom versorge und innerhalb von 5 Sekunden das Pair-Signal (oder irgendein anderes) sende, sollte das doch eigentlich mit jeder ID funktionieren,
oder hab ich das falsch verstanden?
Stehe gerade auf dem Schlauch.
Gruß
Hajo
Moin nochmal,
nach mehrfachem Flashen kann ich nun auch sniffen:
Hier hab ich mal ein paar Tasten in der SmartPhone App gedrückt:
2017.10.14 20:18:55 4 : openMiLiBridge_Read: B0 0F ED E0 01 13 9D
2017.10.14 20:18:55 4 : openMiLiBridge_Read: .
2017.10.14 20:18:58 4 : openMiLiBridge_Read: B0 0F ED E0 01 13 9F
2017.10.14 20:18:58 4 : openMiLiBridge_Read: .
2017.10.14 20:18:58 4 : openMiLiBridge_Read: .
2017.10.14 20:18:58 4 : openMiLiBridge_Read: .
2017.10.14 20:18:58 4 : openMiLiBridge_Read: .
2017.10.14 20:19:01 4 : openMiLiBridge_Read: B0 0F ED E0 02 05 A0
2017.10.14 20:19:01 4 : openMiLiBridge_Read: .
2017.10.14 20:19:01 4 : openMiLiBridge_Read: .
2017.10.14 20:19:01 4 : openMiLiBridge_Read: B0 0F ED E0 02 15 A1
2017.10.14 20:19:01 4 : openMiLiBridge_Read: .
2017.10.14 20:19:01 4 : openMiLiBridge_Read: .
2017.10.14 20:19:01 4 : openMiLiBridge_Read: .
2017.10.14 20:19:04 4 : openMiLiBridge_Read: B0 0F ED E0 01 03 A2
2017.10.14 20:19:04 4 : openMiLiBridge_Read: .
2017.10.14 20:19:04 4 : openMiLiBridge_Read: B0 0F ED E0 01 13 A3
2017.10.14 20:19:04 4 : openMiLiBridge_Read: .
2017.10.14 20:19:04 4 : openMiLiBridge_Read: .
2017.10.14 20:19:04 4 : openMiLiBridge_Read: .
2017.10.14 20:19:04 4 : openMiLiBridge_Read: .
2017.10.14 20:19:04 4 : openMiLiBridge_Read: B0 0F ED 3B 01 0F A4
2017.10.14 20:19:04 4 : openMiLiBridge_Read: .
2017.10.14 20:19:04 4 : openMiLiBridge_Read: .
2017.10.14 20:19:04 4 : openMiLiBridge_Read: B0 0F ED 3B 01 0F A5
2017.10.14 20:19:04 4 : openMiLiBridge_Read: .
2017.10.14 20:19:04 4 : openMiLiBridge_Read: B0 0F ED 3B 01 0F A6
2017.10.14 20:19:05 4 : openMiLiBridge_Read: B0 0F ED 3B 01 0F A7
2017.10.14 20:19:05 4 : openMiLiBridge_Read: .
2017.10.14 20:19:05 4 : openMiLiBridge_Read: .
2017.10.14 20:19:05 4 : openMiLiBridge_Read: B0 0F ED 3B 01 0F A8
2017.10.14 20:19:05 4 : openMiLiBridge_Read: B0 0F ED 3B 01 0F A9
2017.10.14 20:19:05 4 : openMiLiBridge_Read: .
2017.10.14 20:19:05 4 : openMiLiBridge_Read: B0 0F ED 3B 01 0F AA
Also ist die ID meiner iBox1 wohl B00FED.
Hab ich dann auch im Device geändert (von vorher B81234).
Wenn ich aber jetzt Signale sende reagiert die Lampe nicht:
2017-10-14 20:23:24 MilightDevice MiLightBridge.Lampe.Zone1 on 4
2017.10.14 20:23:24 4 : openMiLiBridge_Write: Command: 45 00 55
2017.10.14 20:23:24 4 : openMiLiBridge_Write: Command found: 3
2017.10.14 20:23:24 4 : openMiLiBridge_Write: USBCommand: B00FED000003B3
2017.10.14 20:23:24 4 : openMiLiBridge_Write: Command: C5 00 55
2017.10.14 20:23:24 4 : openMiLiBridge_Write: Command found: 19
2017.10.14 20:23:24 4 : openMiLiBridge_Write: USBCommand: B00FED000013B4
2017.10.14 20:23:24 4 : openMiLiBridge_Write: Command: 4E 02 55
2017.10.14 20:23:24 4 : openMiLiBridge_Write: Brightness: 02..128 - 80
2017.10.14 20:23:24 4 : openMiLiBridge_Write: USBCommand: B00FED00800EB5
2017.10.14 20:23:24 4 : openMiLiBridge_Write: Command: 45 00 55
2017.10.14 20:23:24 4 : openMiLiBridge_Write: Command found: 3
2017.10.14 20:23:24 4 : openMiLiBridge_Write: USBCommand: B00FED000003B6
2017.10.14 20:23:24 4 : openMiLiBridge_Write: Command: C5 00 55
2017.10.14 20:23:24 4 : openMiLiBridge_Write: Command found: 19
2017.10.14 20:23:24 4 : openMiLiBridge_Write: USBCommand: B00FED000013B7
2017.10.14 20:23:24 4 : openMiLiBridge_Write: Command: 4E 02 55
2017.10.14 20:23:24 4 : openMiLiBridge_Write: Brightness: 02..128 - 80
2017.10.14 20:23:24 4 : openMiLiBridge_Write: USBCommand: B00FED00800EB8
2017-10-14 20:23:24 MilightDevice MiLightBridge.Lampe.Zone1 off
2017.10.14 20:23:24 4 : openMiLiBridge_Write: Command: 46 00 55
2017.10.14 20:23:24 4 : openMiLiBridge_Write: Command found: 4
2017.10.14 20:23:24 4 : openMiLiBridge_Write: USBCommand: B00FED000004B9
2017.10.14 20:23:24 4 : openMiLiBridge_Write: Command: 46 00 55
2017.10.14 20:23:24 4 : openMiLiBridge_Write: Command found: 4
2017.10.14 20:23:24 4 : openMiLiBridge_Write: USBCommand: B00FED000004BA
Ich nehme an, dass die Pausen zwischen den Signalen fehlen...
Kann ich das irgendwie beeinflussen?
Gruß
Hajo
Zitat von: bmilos am 12 Juli 2017, 22:22:08
hat sich gelöst, der Scatch hatte einen Fehler :)
hm sieht so aus als ob ich den selben Fehler habe. Kannst du mir einen Tipp bezüglich des Fehlers im Sketch geben?
Gruß
Hajo
Ich verstehe das ansinnen nicht, der NRF kann doch direkt an die GPIOs angeschlossen werden und läuft dann gegen die openmilight bridge software. Wo ist der Vorteil da noch einen Arduino mit zu beschäftigen ?
Zitat von: Dlay am 14 Oktober 2017, 22:57:33
Ich verstehe das ansinnen nicht, der NRF kann doch direkt an die GPIOs angeschlossen werden und läuft dann gegen die openmilight bridge software. Wo ist der Vorteil da noch einen Arduino mit zu beschäftigen ?
Grundsätzlich guter Einwand, aber
-> der Pi ist die Testumgebung
Produktiv läuft der Nano nachher nicht am Pi sondern via USB-Port an einem FHEM Rechner (kein Pi - keine GPIO Pins => Shuttle XS35GTA-V3 http://www.shuttle.eu/de/produkte/discontinued/barebones/xs35gta-v3/ (http://www.shuttle.eu/de/produkte/discontinued/barebones/xs35gta-v3/)).
So ich hab mir die App noch mal genauer angeschaut.
Da ich keine Fernbedienung habe, musste ich etwas rumprobieren und habe folgendes herausgefunden.
Es gibt wohl 15 verschiedene Fernbedienungen, die man in der Mi-Light 3.0 App auswählen kann (Stand -> IOS Version 7.1.2/ Android Version 3.7).
Diese füge ich mal der Übersicht halber durchnummeriert bei.
Auch ohne die entsprechende Fernbedienung kann ich die Lampen auf die verschiedenen Fernbedienungstypen linken.
Das hab ich gemacht, weil die verschiedenen Fernbedienungen auch immer (teilweise nur leicht) unterschiedliche Protokolle fahren.
Interessanterweise scheinen meine Lampen (relativ alte FUT014) sich mit jeder Fernbedienung linken zu lassen,
woraus ich schließe dass sich das Protokoll zwischen Bridge und den Lampen nicht geändert hat.
Mit dem Openmili-Adapter kann ich nur die Fernbedienungen Typ 2,3,4 und 5 sniffen, welche dann wohl das Protokoll V3-5 nutzen.
Alle anderen werden nicht erkannt. Ich nehme an diese fahren das Protokoll V6,
was wohl im allgemeinen als das "neue MiLight"- oder 2016er-Protokoll bezeichnet wird und im openmili noch nicht implementiert ist.
Genau das war auch der Grund, warum ich am Anfang der Meinung war ich konnte nicht sniffen:
Meine Fernbedienung war auf Typ 1 eingestellt und die Lampen gelinkt. Damit kommt in Fhem nix an.
Leider komme ich immer noch nicht weiter mit dem Senden von Signalen.
Da bin ich immer noch der Meinung dass die Pausen zwischen den Signalen fehlen.
Kann mir mal jemand einen Tip mit dem Sketch geben, bei dem das schon läuft?
Oder alternativ mal einen funktionsfähiges hex-File uploaden?
Danke!
Gruß
Hajo