Milights steuern ohne WLAN (via openMili an USB)

Begonnen von KernSani, 05 März 2017, 21:46:25

Vorheriges Thema - Nächstes Thema

KernSani

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 ist das ganz schön beschrieben.
Schritt 2: Den openMili Sketch auf dem Nano zum Laufen bringen.
Schritt 3: ID deiner Milights-Fernbedienung sniffen (Details dazu z.B. hier)
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.
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

ToM_ToM

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
Hardware: BananaPi, Busmaster CUL, SanDisk 16GB Ultra SD, 16 GB USB-Stick | Software: Armbian, FHEM 5.8

Beta-User

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

jlanzing

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

KernSani

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
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Beta-User

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

bmilos

#6
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
Raspberry Pi 3, nanoCUL 433, FHEMduino, HMLAN, Homematic, Intertechno, MiLight, MySensor

bmilos

hat sich gelöst, der Scatch hatte einen Fehler :)
Raspberry Pi 3, nanoCUL 433, FHEMduino, HMLAN, Homematic, Intertechno, MiLight, MySensor

TomLee

#8

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 5

hab ich geändert in

Define mi_Wecklicht2 MilightDevice RGBW openMili 5

welches 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 C1C18C1


Nach 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 










TomLee

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

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 ?


Sequenzial

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

Sequenzial

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

Sequenzial

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

Dlay

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 ?

Sequenzial

#14
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/).