Eigentlich wollte ich nur die Milight Bridges durch einen ESP8266 ersetzen......

Begonnen von schka17, 09 Oktober 2016, 16:33:55

Vorheriges Thema - Nächstes Thema

hexenmeister

Habe heute ein wenig rumprobiert und kann meine Lampen jetzt steuern. Paaren klappte per MiLight-Modul immer noch nicht, daher habe ich die Lampen mit der OriginalFB gepaart und die ID der FB in den Script 'einkompiliert' (MQTT-Version). Funktioniert. Reichweie mit E27 Lampe ganz ok, reicht für ein Zimmer locker. Bei GU10 Lampen war die Reichweite schon deutlich schlechter.

Ich möchte noch mit WifiLight ausprobieren und evtl. den Sketch etwas umschreiben, muss nur noch Zeit dafür finden >:(

Den Sketch habe ich schon ein wenig 'repariert', jetzt klappt auch das Verbinden mit dem AP, wenn WLAN-Verbindungsdaten falsch sind, sodass man das Modul umkonfigurieren kann.

Was ich mir noch vorstellen könnte im WebConfig einzubauen:
- Abschaltbare MQTT-Feature (damit könnte man ein Sketch für alle benutzen)
- Konfigurierbare FB-IDs
- k.P., mir fällt bestimmt noch was ein ;D
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Beta-User

Hallo Hexenmeister,

also nur ein Zimmer als Reichweite ist nicht viel, meine Bridge (s.u., es hängt ein seperater Kondensator am nRF) deckt das ganze Haus ab, die Reichweite ist damit eher besser als das WLAN der Fritte (7390). Vermutlich ist das Signal schlicht nicht stark genug für das pairen.

Das ganze konfigurierbar zu machen, ist eine gute Sache (AP-Daten und auch das mit den FB-ID's).

Wenn Du noch eine Idee brauchst:
Ein richtiger Rückweg zu Wifilight (oder MiLight) wäre klasse für die Leute, die neben FHEM noch Fernbedienungen nutzen. Leider übersteigt das Trennen der Elemente meinen aktuellen programmiertechnischen Horizont, aber eigentlich sollte das nicht so schwer sein, wenn FB's und die Bridges dieselben Kennungen nutzen.
Im Prinzip müßte man nur die Logik, wie die Elemente in der Bridge zusammengesetzt werden rückwärts gehen und sich dann noch eine Methode überlegen, wie man das zurück an FHEM meldet (möglichst ohne MQTT, vielleicht ginge eine Art serialBridge; ich hatte auch an MySensors rumüberlegt, aber mehrere GW's sind da nicht so das gelbe vom Ei).

Jedenfalls Danke für's 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

hexenmeister

Moin!
Die empfangenen Daten einer FB auf Serialport auszugeben sollte nicht so schwer sein, aber in welcher Form und wer bringt das dem Fhem-Modul bei?

Einen kleinen Kondensator habe ich auch dran gelötet und die Reichweite mit e27 Lampe kenne ich eigentlich nicht wirklich, habe gar nicht außerhalb eines Zimmers probiert  ;D Nur die vier GU10, die ich anstelle normalen Lampen zum Testen unter die Decke gebracht habe, wollten nicht so recht. Mal reagierten zwei, mal drei, mal gar keine. Auf die FB hörten sie aber gut.
Ich muss mehr testen.

Grüße
Alexander
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Gunther

Ich frage mich gerade, wie ich nun vorgehe, um erfolgreich zu sein.
Muss ich etwas neu flashen? Falls ja: wie und mit welcher Soft- und Hardware?

VG
Gunther
FHEM@Proxmox@Nuc: TabletUI als User-Interface (4 Wandtablets) / IOs per ser2net gekapselt
Homematic: Heizung, Fenster, Bewegung | Jeelink: Temperatur | Z-Wave: Bewegung, Temperatur | FS20: Temperatur, Fenster | Viessmann-Heizung eingebunden

Beta-User

@Gunther:
Sieht eher nicht danach aus, als wäre es ein SW-Thema. Sofern Du die gesockelte Version des GW hast: Tausche den nRF mal, am besten gegen einen mit externer Antenne. Es gibt da auch China-Clone, die nicht so gut sind bzw. auch deutlich mehr Strom brauchen, da kann das Anlöten eines Kondensators deutliche Verbesserung bringen.
Ansonsten: klappt die Steuerung mit den "normalen" Bridges? Dazu kannst Du ja einfach die Definition eines Kanals in FHEM ändern (wg. der Reihenfolge das Ladens in fhem.cfg, das kann das Duo Milight_Bridge/Milight_Device eher auch nicht richtig).

Wenn Du selbst die firmware flashen willst: Nimm doch den Wemos zum testen... Dazu die Arduino-IDE installieren (unter Linux am besten erst mal über die Paketverwaltung wegen der zusätzlich benötigten Pakete, dann wieder deinstallieren und die aktuelle Version von arduino.cc holen), die Werkzeuge für ESP8266 installieren (in der IDE bei Datei->Voreinstellungen als Boardverwalter-URL http://arduino.esp8266.com/stable/package_esp8266com_index.json eintragen und dann mit dem Board-Manager runterladen), eines der Packages in diesem Thread nehmen, WLAN-Daten anpassen, Kompilieren versuchen, die als fehlend anmonierten Libraries nachinstallieren. That's it. Wenn Du die ID Deiner Fernbedienung bzw. Bridge sehen willst, entweder die MQTT-Variante nehmen, oder die V4 etwas anpassen (da ist der receiving-Teil deaktiviert, das aktivieren,siehe einen meiner Beiträge weiter oben. Dann kommt die Ausgabe auf dem seriellen Monitor, den man in der IDE einschalten kann).

@Alexander:
Zitatin welcher Form und wer bringt das dem Fhem-Modul bei
Wenn ich das wüßte...
Ansätze, basierend auf Milight (ist aber nur ein fork von wifilight, das man m.E. als Basis nehmen sollte und vermutlich ähnlich tickt):
- Soweit ich das verstanden habe, generiert man in FHEM beim Steuern eines Milight-Devices eigentlich nur den "mittleren" Teil des Steuercodes. Alles andere geschieht dann auf der Ebene Kanal (letztes Byte) bzw. Bridge (erste 3 Bytes). Die Bridge rechnet dann die erhaltenen Kern-Steuerinformationen noch um und setzt das mit den "Rahmen"Bytes zusammen zu einem End-Steuersignal.
- Man müßte also diese 3 Informationen auswerten. M.E. wäre das auf der mC-Ebene einfacher, jedenfalls, wenn die FB-ID's dort bekannt sind. Für die Kanalinfo gibt es eh' nur 5 Möglichkeiten (1-4 bzw. alle).
- Somit könnte man das vorverarbeitet an FHEM zurücksenden und bräuchte dann eine Logik, die das wieder dem FHEM-Device zuordnet (was aber immer gleich sein könnte, da der Rahmen gleich wäre).
- Alternativ wäre es evtl. möglich, den ganzen FB-Code zu nehmen, dann müßte man aber den Devices noch readings zuordnen für FB-ID und Kanal und auch die Rückrechnung des Kern-Steuercodes in perl erledigen.
Leider habe ich da keine wirkliche Idee, was da einfacher ist, bis jetzt bin ich froh, wenn ich C-Code copy/paste so zusammenstellen kann, dass meine Arduinos tun, was sie sollen (?)... Daher auch der Ansatz, das eher auf mC-Ebene vorzuverarbeiten.

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

hexenmeister

Gunther hat seine Hardware von mir. Absolut baugleiche Version hat gestern bei mir ja grundsätzlich funktioniert (bis auf Paaren). Seine Versionen sind nicht gesockelt, wäre aber auch kein Problem, wenn ein Funkchip mit Antenne die Lösung, löte ich seine Module um (kann leider nicht selbst mit den Antennenmodulen testen - habe gerade keine). Ich werde bei mir aber vorher mit anderen Größen der Stütz-Kondensatoren probieren, auch wenn da schon welche sind...
@Gunther: wollen wir so verbleiben? Ich versuche noch zu paaren mit WifiLight und dann noch andere Kondensatoren, danach sehen wir, wie wir deine Module zum Laufen bekommen.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Zum Theme Rückmeldung an MilightBridge/WifiLight...
Per Serial ist natürlich hier Quatsch, wenn ich so überlege, der Weg zurück muss natürlich auch per WLAN gehen. Im Sketch sehe ich dabei keine Schwierigkeiten, aber wie das im FHEM-Modul zu machen wäre - da bäuchte man Hilfe des Entwicklers der Module.
Per MQTT könnte man das jetzt schon realisieren, auch wenn mit einigen Umwegen: Fernbedienung->Sketch->MQTT-Server->MQTT_DEVICE->notify (zum entsprechenden Umformen und setzen in MiLight_Device)->MILIGHT_DEVICE.

Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Beta-User

Zu "serial":

Vorab: eine echte serielle (USB)-Lösung wäre mir persönlich am liebsten, eine reine Arduino-Lösung scheitert ja derzeit nur an der Kompabilität zu den Modulen und den Ports für das Auseinanderhalten der mehreren virtuellen Bridges. Rückwärts hatte ich daher den Begriff "serialBridge" benutzt. Gemeint war damit, ein quasi-serielles Signal über WLAN zurückzumelden; wie man das im Einzelnen macht: keinen Schimmer... Ich könnte auch mit einer seriellen Ausgabe am ESP leben, der hängt bei mit eh' direkt neben dem PI, bekommt allerdings den Strom von der Fritte.

Was MQTT angeht: zum einen wollte ich mir das nicht unbedingt auch noch "antun", zum anderen fühle ich mit dem Entwurf des notify/myUtils-Codes etwas überfordert, ich habe schon Schwierigkeiten, den C-Code vorwärts zu verstehen; ihn auf mC-Ebene umzudrehen, wird schon schwierig genug, aber dann perl?... Aber wenn dieser "MQTT-Rückweg" ausentwickelt wäre, würde ich uU. auch das machen, ist ja auch keine Raketenwissenschaft.

Alternativ hatte ich die Idee, die Bridge zusätzlich als MySensors-Bridge zu coden und zu definieren und dann nur den vorverarbeiteten FB-Code darüber zurückzuschicken (statt MQTT, code als lokaler Sensor für IR bzw. 433MHz-Beispiel nachgebildet). Allerdings hat das Verwenden mehrerer MySensors-Bridges auch so seine Tücken (nutze derzeit nRF und RS485-GW's parallel, beide seriell. Die Neuanlage von Devices ist damit aber suboptimal). Alles aber halt noch nicht ausgegoren und getestet.

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

hexenmeister

Habe heute mit WifiLight herumgespielt
define wmilight1 WifiLight RGBW2 bridge-V3:192.168.0.109

Auch hier funktioniert pair/unpair nicht. Wieder haufenweise Meldungen im Log:

2017.03.22 19:53:29 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/32_WifiLight.pm line 3762.
2017.03.22 19:53:29 1: stacktrace:
2017.03.22 19:53:29 1:     main::__ANON__                      called by ./FHEM/32_WifiLight.pm (3762)
2017.03.22 19:53:29 1:     main::WifiLight_HighLevelCmdQueue_Add called by ./FHEM/32_WifiLight.pm (2898)
2017.03.22 19:53:29 1:     main::WifiLight_RGBW2_Pair          called by ./FHEM/32_WifiLight.pm (750)
2017.03.22 19:53:29 1:     main::WifiLight_Set                 called by fhem.pl (3307)
2017.03.22 19:53:29 1:     main::CallFn                        called by fhem.pl (1651)
2017.03.22 19:53:29 1:     main::DoSet                         called by fhem.pl (1683)
2017.03.22 19:53:29 1:     main::CommandSet                    called by fhem.pl (1108)
2017.03.22 19:53:29 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2430)
2017.03.22 19:53:29 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (888)
2017.03.22 19:53:29 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (535)
2017.03.22 19:53:29 1:     main::FW_Read                       called by fhem.pl (3312)
2017.03.22 19:53:29 1:     main::CallFn                        called by fhem.pl (675)
2017.03.22 19:53:29 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/32_WifiLight.pm line 3762.

Ich habe langsam ein Verdacht, dass diesbezüglich etwas in minem System nicht stimmt.

Steuern kann ich meine E27 Lampe damit sehr gut. Und auch weit - deckt meine Etage komplett ab.
Dagegen wollen meine GU10 Lampen uns Verrecken nicht ordentlich zuhören. Es geht schon, aber nur sporadisch - aus den 4 Lampen hört mal eine, mal zwei aber nie alle zusammen, auch dann nicht, wenn der Abstand ein Bruchteil davon ist, wie zu der E27 Lampe, die gleichzitig brav schaltet und dimmt >:(

Also nach Hardware sieht es für mich nicht aus...

Nur wie bringen ich dem Ding das Paaren bei...
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

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

schka17

Zitat von: hexenmeister am 14 März 2017, 18:29:33
@schka17 hast du ggf. was dagegen, wenn ich die Sourcen in mein GitHub hochlade?
Sorry war ein paar ein paar Wochen in Afrika und habe nichts gelesen, ja klar kein Problem


Sent from my iPad using Tapatalk
M: Thinclient x64 Debian | CUL FS20, HMS100WD, HMS100TF, HMS100T, HMS100CO, S300, S555TH | OWServer DS1420, DS18B20, DS2408 | RFXCOM UVN128, THWR800, THGR228N,RTGR328, PCR800 |Jeelink PCA301 EC3000|CUNO+IR|HMLAN|HMUSB|CUL433 Somfy|mySensors|espEasy
S1:Raspberry mit BPM810, Jeelink EC3000

schka17

Zu den Problemen mit dem pairen, das habe auch ich immer mal, egal ob Milight module oder Wifilight. Ich habe die RBGw E27 und ledstrip controller im Einsatz. Einige musste ich mit einer FB unpairen, erst dann konnte ich sie wieder mit FHEM pairen, ander haben sofort funktioniert. Zum pairen reicht es, gleich nach der Stromzufuhr irgendeinen Befehl zu senden. Unpairen funktioniert mit keinem FHEM modul (bei mir) auch nicht mit der original bridge.

Den MQTT sketch habe ich zuerst eigentlich nur als proof of concept gebastelt, dann aber auch "sniffer" fürs milight Protokoll eingesetzt, aber einen produktiven Einsatz habe ich nicht, verwende keine FB's , die milights werden nur aus FHEM gesteuert.


Sent from my iPad using Tapatalk
M: Thinclient x64 Debian | CUL FS20, HMS100WD, HMS100TF, HMS100T, HMS100CO, S300, S555TH | OWServer DS1420, DS18B20, DS2408 | RFXCOM UVN128, THWR800, THGR228N,RTGR328, PCR800 |Jeelink PCA301 EC3000|CUNO+IR|HMLAN|HMUSB|CUL433 Somfy|mySensors|espEasy
S1:Raspberry mit BPM810, Jeelink EC3000

Tom71

Ich bin etwas überrascht, da bei mir die Bridge und die Fernbedienung gleichzeitig funktionieren. Ich habe die Lampen zuerst an der Bridge angelernt, Sketch ist "# OpenMiLight Receiver/Transmitter starting om5_OTA_MQTT" und habe nur die WLAN Daten eingetragen. Nach ein paar Tagen kam meine Fernbedienung und ich hab die Lampen damit angelernt.
Einige kann ich sowohl mit der FB als auch mit der Bridge bedienen, andere wieder nicht.
Was muss ich denn als ID mit in den Sketch kompilieren, damit beides funktioniert?
Und wo muss ich das eintragen?

Diese Lampen funktionieren mit FB und Bridge:
Off: FB

Packetsize : 7
incoming subscribe: ESP8266_1730800/Milight/Remote/Type | B0
incoming subscribe: ESP8266_1730800/Milight/Remote/Address | 534D
incoming subscribe: ESP8266_1730800/Milight/Remote/Color | 38
incoming subscribe: ESP8266_1730800/Milight/Remote/Brightness | BC
incoming subscribe: ESP8266_1730800/Milight/Remote/CMD | 6
incoming subscribe: ESP8266_1730800/Milight/Remote/Counter | 50
.....

On: FB
Packetsize : 7
incoming subscribe: ESP8266_1730800/Milight/Remote/Type | B0
incoming subscribe: ESP8266_1730800/Milight/Remote/Address | 534D
incoming subscribe: ESP8266_1730800/Milight/Remote/Color | 38
incoming subscribe: ESP8266_1730800/Milight/Remote/Brightness | BA
incoming subscribe: ESP8266_1730800/Milight/Remote/CMD | 5
incoming subscribe: ESP8266_1730800/Milight/Remote/Counter | 51


Off - Bridge
Contents: 49 0 55
Write : B0 63 D2 0 F1 7 27
........
Contents: C9 0 55
Write : B0 63 D2 0 F1 17 28
................
Contents: 4E 2 55
Write : B0 63 D2 0 83 E 29
.........
Contents: 49 0 55
Write : B0 63 D2 0 83 7 2A
................
Contents: C9 0 55
Write : B0 63 D2 0 83 17 2B
..........
Contents: 4E 2 55
Write : B0 63 D2 0 83 E 2C
................
Contents: 4A 0 55
Write : B0 63 D2 0 83 8 2D
................
Contents: 4A 0 55
Write : B0 63 D2 0 83 8 2E

On: Bridge

Contents: 49 0 55
Write : B0 63 D2 0 83 7 2F

Contents: C9 0 55
Write : B0 63 D2 0 83 17 30
..
Contents: 4E 13 55
Write : B0 63 D2 0 FB E 31
................
Contents: 49 0 55
Write : B0 63 D2 0 FB 7 32
....
Contents: C9 0 55
Write : B0 63 D2 0 FB 17 33
................
Contents: 4E 13 55
Write : B0 63 D2 0 FB E 34


Diese nicht: Off: FB

incoming subscribe: ESP8266_1730800/Milight/Remote/Type | B0
incoming subscribe: ESP8266_1730800/Milight/Remote/Address | 534D
incoming subscribe: ESP8266_1730800/Milight/Remote/Color | 43
incoming subscribe: ESP8266_1730800/Milight/Remote/Brightness | 52
incoming subscribe: ESP8266_1730800/Milight/Remote/CMD | 8
incoming subscribe: ESP8266_1730800/Milight/Remote/Counter | 74


Off FB:
incoming subscribe: ESP8266_1730800/Milight/Remote/Type | B0
incoming subscribe: ESP8266_1730800/Milight/Remote/Address | 534D
incoming subscribe: ESP8266_1730800/Milight/Remote/Color | 43
incoming subscribe: ESP8266_1730800/Milight/Remote/Brightness | 53
incoming subscribe: ESP8266_1730800/Milight/Remote/CMD | 8
incoming subscribe: ESP8266_1730800/Milight/Remote/Counter | 77


Vielen Dank
Homematic | RaspberryMatic

schka17

Zitat von: Tom71 am 11 April 2017, 21:28:16
Ich bin etwas überrascht, da bei mir die Bridge und die Fernbedienung gleichzeitig funktionieren. Ich habe die Lampen zuerst an der Bridge angelernt, Sketch ist "# OpenMiLight Receiver/Transmitter starting om5_OTA_MQTT" und habe nur die WLAN Daten eingetragen. Nach ein paar Tagen kam meine Fernbedienung und ich hab die Lampen damit angelernt.
Einige kann ich sowohl mit der FB als auch mit der Bridge bedienen, andere wieder nicht.
Was muss ich denn als ID mit in den Sketch kompilieren, damit beides funktioniert?
Und wo muss ich das eintragen?

Diese Lampen funktionieren mit FB und Bridge:
Off: FB

Packetsize : 7
incoming subscribe: ESP8266_1730800/Milight/Remote/Type | B0
incoming subscribe: ESP8266_1730800/Milight/Remote/Address | 534D
incoming subscribe: ESP8266_1730800/Milight/Remote/Color | 38
incoming subscribe: ESP8266_1730800/Milight/Remote/Brightness | BC
incoming subscribe: ESP8266_1730800/Milight/Remote/CMD | 6
incoming subscribe: ESP8266_1730800/Milight/Remote/Counter | 50
.....

On: FB
Packetsize : 7
incoming subscribe: ESP8266_1730800/Milight/Remote/Type | B0
incoming subscribe: ESP8266_1730800/Milight/Remote/Address | 534D
incoming subscribe: ESP8266_1730800/Milight/Remote/Color | 38
incoming subscribe: ESP8266_1730800/Milight/Remote/Brightness | BA
incoming subscribe: ESP8266_1730800/Milight/Remote/CMD | 5
incoming subscribe: ESP8266_1730800/Milight/Remote/Counter | 51


Off - Bridge
Contents: 49 0 55
Write : B0 63 D2 0 F1 7 27
........
Contents: C9 0 55
Write : B0 63 D2 0 F1 17 28
................
Contents: 4E 2 55
Write : B0 63 D2 0 83 E 29
.........
Contents: 49 0 55
Write : B0 63 D2 0 83 7 2A
................
Contents: C9 0 55
Write : B0 63 D2 0 83 17 2B
..........
Contents: 4E 2 55
Write : B0 63 D2 0 83 E 2C
................
Contents: 4A 0 55
Write : B0 63 D2 0 83 8 2D
................
Contents: 4A 0 55
Write : B0 63 D2 0 83 8 2E

On: Bridge

Contents: 49 0 55
Write : B0 63 D2 0 83 7 2F

Contents: C9 0 55
Write : B0 63 D2 0 83 17 30
..
Contents: 4E 13 55
Write : B0 63 D2 0 FB E 31
................
Contents: 49 0 55
Write : B0 63 D2 0 FB 7 32
....
Contents: C9 0 55
Write : B0 63 D2 0 FB 17 33
................
Contents: 4E 13 55
Write : B0 63 D2 0 FB E 34


Diese nicht: Off: FB

incoming subscribe: ESP8266_1730800/Milight/Remote/Type | B0
incoming subscribe: ESP8266_1730800/Milight/Remote/Address | 534D
incoming subscribe: ESP8266_1730800/Milight/Remote/Color | 43
incoming subscribe: ESP8266_1730800/Milight/Remote/Brightness | 52
incoming subscribe: ESP8266_1730800/Milight/Remote/CMD | 8
incoming subscribe: ESP8266_1730800/Milight/Remote/Counter | 74


Off FB:
incoming subscribe: ESP8266_1730800/Milight/Remote/Type | B0
incoming subscribe: ESP8266_1730800/Milight/Remote/Address | 534D
incoming subscribe: ESP8266_1730800/Milight/Remote/Color | 43
incoming subscribe: ESP8266_1730800/Milight/Remote/Brightness | 53
incoming subscribe: ESP8266_1730800/Milight/Remote/CMD | 8
incoming subscribe: ESP8266_1730800/Milight/Remote/Counter | 77


Vielen Dank
Dafür brauchst du im Sketch nichts ändern, das pairing findet ja in der Lampe statt. Wenn ich mich richtig erinnere kann man bis zu 4 FB's oder Bridges anlernen. Ich hatte auch bei verschiedenen Lampen bzw. Led Controllern dieses Problem. Am einfachsten ist die pairings mit der FB zu löschen und dann Bridge und FB nochmal anzulernen.


Sent from my iPad using Tapatalk
M: Thinclient x64 Debian | CUL FS20, HMS100WD, HMS100TF, HMS100T, HMS100CO, S300, S555TH | OWServer DS1420, DS18B20, DS2408 | RFXCOM UVN128, THWR800, THGR228N,RTGR328, PCR800 |Jeelink PCA301 EC3000|CUNO+IR|HMLAN|HMUSB|CUL433 Somfy|mySensors|espEasy
S1:Raspberry mit BPM810, Jeelink EC3000

heikoxxxx

Hallo Leute,

erstmal vielen Dank für die Entwicklung dieses Gateways und der Programmierung. Funktioniert soweit einwandfrei, bis auf die Farben. Wie auch einige Beiträge vor mir habe ich bei rot einen lilaton. Somit ist das ganze irgendwie verschoben. Kann das an den Lampen liegen oder was kann ich daran ändern?

Zudem wenn ich die Disco modes aufrufe passiert nichts weiter, als das die Lampe etwas heller wird wenn Sie davor aus war.

Ich hatte eine Ibox2 über amazon mit den entsprechenden Lampen erhalten. Kann es sein, dass sich auch die Funkdaten geändert haben. Auf den Lampen selbst finde ich keinen Hinweis auf eine Version.

LG Heiko