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

herrmannj

Mililight stammt vom wifilight Code. Wird ähnlich sein. Du kannst aber auch mit App oder fb unpair machen. Ein unpair löst *alle* pairings. Will sagen ein unpair mit fb löst auch gleich alle gepairten bridges..

Vg joerg

Beta-User

Zitat von: schka17 am 10 Oktober 2016, 22:59:00
Ich habe gesehen beim Milight Device gibt es auch pair und unpair
Nur zur Klarstellung, ich habe NICHT einen speziellen pair oder unpair-Befehl ausgewählt!

Es handelte sich um eine schlichte empirische Beobachtung unter folgenden Rahmenbedingungen:
Steuerung über FHEM über aktuelle MilightBridge und MilightDevice. Das MilightDevice hat u.A. folgendes attribut:
webCmd on:off:dim:hue:night:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffff00 deleteattr

Klicke ich dort nach dem physischen Anschalten auf die Fläche für ganz hell (rgb ffffff), hatte ich bei der einen getesteten Milight-Bulb (9W =LEDTYPE RGBW) das Ergebnis, dass die sich zuverlässig paired und unpaired. Als readings habe ich:
hsv 0,0,40 2016-10-10 21:02:45
hue 0 2016-10-10 21:02:45
previousState 0,0,100 2016-10-10 21:02:45
rgb 666666 2016-10-10 21:02:45

Meine weiteren Annahmen und Beobachtungen:
- die Bridge selbst kennt keine Dauer für irgendeinen Klick (anders als die FB), daher läge es nahe, dass die Länge des Sendebefehls  kein originäres Kriterium ist (und möglicherweise auch nicht die Zahl der Widerholungen).
- Die FB's schalten bei längerem Druck um vom reinen An/Aus auf "Maximal hell, Modus weiss" (im Normalbetrieb, wenn die Bulb schon länger Spannung hat). Das deckt sich mit der Beobachtung von Karl beim sniffen, dass der Code wechselt.

Wie gesagt, singuläre Beobachtung, inwieweit das zur Theorie (und zur Doku bzw. zu anderen Device-Typen) passt, ist eine andere Sache, und ich habe auch nicht untersucht, wie das das Duo MilightDevice/MilightBridge intern in Kommandos an die Bridge umsetzt.

Zitat von: herrmannj am 11 Oktober 2016, 00:04:06
Ein unpair löst *alle* pairings. Will sagen ein unpair mit fb löst auch gleich alle gepairten bridges..
Wieder was gelernt;
Es gibt die FB's ja in mehreren Fassungen. Ich habe hier welche, die 4xRGB steuern können, also einen Einzel- und Gruppenmodus haben. Ist das nur so, wenn man den "Hauptschalter" oben nimmt, oder auch, wenn man "unten" auf "on" bleibt? (Ich wollte das nicht unbedingt testen, das gibt sonst lange Gesichter ;))
Der Aspekt ist nicht so lustig, es gab zwar hier bisher keine ernsthaften Probleme, aber vielleicht sieht jemand eine Möglichkeit, zumindest zu verhindern, dass über FHEM solche Befehle unbeabsichtigt versendet werden...
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

herrmannj

@Karl
schon verstanden. Wollte sagen: wenn es "nur" darum geht einige bulbs, die per "Unfall" gepaired sind, wieder frei zu bekommen: nimm Dir eine FB, paire die bulb mit fb unpaire direkt mit der fb.

@beta-user
das sich die bulb paired wenn Du direkt nach "Spannung-da" einen Befehl absetzt ist bekannt. Kommt daher wie milight das protokoll gestrickt hat. Btw, das geht nicht nur mit "rgb ffffff" sondern auc mit vielen anderen.

Unpair auf diese Art auszulösen wäre mir schleierhaft.

vg
joerg

schka17

Zitat von: herrmannj am 11 Oktober 2016, 09:15:10
@Karl
schon verstanden. Wollte sagen: wenn es "nur" darum geht einige bulbs, die per "Unfall" gepaired sind, wieder frei zu bekommen: nimm Dir eine FB, paire die bulb mit fb unpaire direkt mit der fb.

@beta-user
das sich die bulb paired wenn Du direkt nach "Spannung-da" einen Befehl absetzt ist bekannt. Kommt daher wie milight das protokoll gestrickt hat. Btw, das geht nicht nur mit "rgb ffffff" sondern auc mit vielen anderen.

Unpair auf diese Art auszulösen wäre mir schleierhaft.

vg
joerg

Danke, man lernt doch nie aus (steht das irgendwo? ich meinte alles gelesen zu haben)....

FB löst alle pairings (sehe ich zwar im Normalbetrieb nicht als optimal, aber jetzt beim testen ist das super), und Beta-Users Aussage kann ich auch bestätigen, mit der 6W RGBWW Lampe und mit dem RGB Led-strip Controller. Ich musste nur im WifiLight device ramp auf 0 setzen, dann kann ich pairen und unpairen.

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

Beta-User

Dass das Pairen auch mit anderen Befehlen klappt, war mir ebensowenig bewußt, wie das Löschen aller Pairings über den Dauerdruck auf der FB. Nach https://hackaday.io/project/5888-reverse-engineering-the-milight-on-air-protocol/log/18529-command-and-control kommt wohl nach der häufigen (27x?) Wiederholung desselben Befehls dann ein 3xiger neuer Befehl.

Das sind ja echt grobe Fallen! Das mit dem Pairing vor allem, wenn man mehrere von den Dingern an Schaltern hat und viele Schaltbefehle versendet, z.B. Transitions (? das nutze ich nicht). Sollte man dann nicht (mindestens aus diesem Grund) allgemein davon abraten, die Milights überhaupt (jedenfalls in Kombination mit Schaltern) zu verwenden? Es würde aber manche Phänomene erklären, die beim Neustart des PI zu beobachten sind :o.

Na ja, wieder was gelernt...
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

herrmannj

Ja korrekt. Milight sollte immer am netz sein. Ansonsten ist frust vorprogrammiert

Vg
Joerg

Beta-User

Zitat von: schka17 am 13 Oktober 2016, 22:22:35
Ich verwende dein Template um mein Milight Gateway zu erweitern, und zwar um Kommunikation über MQTT anstatt UDP.

Ich schaffe es aber einfach nicht die gesnifften Werte unit_8 in Hex Werte und in ein format umzuwandeln um den das publish KOmmando abzusetzen:

Welches Format muss die Variable haben die hier durch "ValuData" dargestellt wird? bzw. wie kann ich die aus einer unit_8 convertieren? ich verzweifle schön langsam, alles suche hat bis jetzt auch nichts gebracht.

Hallo Karl,

ich weiß nicht, ob der code funktioniert, aber für Infrarot gibt es hier ein Beispiel für einen Empfänger incl. publish.
Da IR-Codes üblicherweise auch in HEX angegeben werden, könnte das als Basis dienen, oder?

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

schka17

Zitat von: Beta-User am 14 Oktober 2016, 07:14:17
Hallo Karl,

ich weiß nicht, ob der code funktioniert, aber für Infrarot gibt es hier ein Beispiel für einen Empfänger incl. publish.
Da IR-Codes üblicherweise auch in HEX angegeben werden, könnte das als Basis dienen, oder?

Gruß,

Beta-User
Hi Beta-User,
das Problem ist nicht der Inhalt oder HEX Format, sondern das die Funktion eine Variable char* erwartet, ich hab alle möglichen (char, string usw) ausprobiert,  aber nix hat funktioniert. Aber ich hab gesehen das in dem verlinkten Code ein conversion drin sind, das muss ich mal probieren, also danke dafür.

Vg

Karl



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

Beta-User

Zitat von: schka17 am 14 Oktober 2016, 08:01:54
Hi Beta-User,
das Problem ist nicht der Inhalt oder HEX Format, sondern das die Funktion eine Variable char* erwartet, ich hab alle möglichen (char, string usw) ausprobiert,  aber nix hat funktioniert. Aber ich hab gesehen das in dem verlinkten Code ein conversion drin sind, das muss ich mal probieren, also danke dafür.

Hi Karl,

das kommt mir bekannt vor, ich hatte das Problem mal im Zusammenhang mir IR; ohne r_knipps Hilfe wäre das nichts geworden, bin auch nur im Kreis gelaufen (r_knipp auch...).
Im Ergebnis haben wir das so gelöst (Ergebnis war ein char*!), wobei wir neben dem reinen IR-Code eben noch das Protokoll und die Code-Länge mit verwurstelt haben:

char buffer[24];
      uint8_t IrBits = My_Decoder.bits;
      String IRType_string = Pnames(My_Decoder.decode_type);
      char IRType[IRType_string.length() + 1];
      IRType_string.toCharArray(IRType, IRType_string.length() + 1);
      sprintf(buffer, "%i 0x%08lX %i, %s", My_Decoder.decode_type, My_Decoder.value, IrBits, IRType);
      // Send ir result to gw
send(msgIr.set(buffer));


Sieht nicht schön aus, ich weiß bis heute nicht, ob das optimal ist, aber es hat funktioniert...
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

Danke,

Ich schau mir das nächste Woche weiter an, jetzt gehts mal in Eishocke Trainingslager.

Nur als Info, Hexenmeisters Mysensor Gateway läuft mit der firmware aus dem ersten Post seit einer Woche problemlos, kein Vergleich zur Milight Bridge.


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

Zitat von: Beta-User am 14 Oktober 2016, 08:39:20
Hi Karl,

das kommt mir bekannt vor, ich hatte das Problem mal im Zusammenhang mir IR; ohne r_knipps Hilfe wäre das nichts geworden, bin auch nur im Kreis gelaufen (r_knipp auch...).
Im Ergebnis haben wir das so gelöst (Ergebnis war ein char*!), wobei wir neben dem reinen IR-Code eben noch das Protokoll und die Code-Länge mit verwurstelt haben:

char buffer[24];
      uint8_t IrBits = My_Decoder.bits;
      String IRType_string = Pnames(My_Decoder.decode_type);
      char IRType[IRType_string.length() + 1];
      IRType_string.toCharArray(IRType, IRType_string.length() + 1);
      sprintf(buffer, "%i 0x%08lX %i, %s", My_Decoder.decode_type, My_Decoder.value, IrBits, IRType);
      // Send ir result to gw
send(msgIr.set(buffer));


Sieht nicht schön aus, ich weiß bis heute nicht, ob das optimal ist, aber es hat funktioniert...

eigentlich eh ganz einfach wenn man weiss wie es geht....

schaut schon gut aus

ESP8266_797742/Control/Status/WiFi on
ESP8266_797742/Control/Status/WiFi off
ESP8266_797742/Control/Status/MQTT on
ESP8266_797742/Control/Status/MQTT off
ESP8266_797742/Milight/Remote/Type B0
ESP8266_797742/Milight/Remote/Address 382C
ESP8266_797742/Milight/Remote/Command C4.21.3
ESP8266_797742/Milight/Remote/Counter 33
ESP8266_797742/Milight/Remote/Type B0
ESP8266_797742/Milight/Remote/Address 382C
ESP8266_797742/Milight/Remote/Command C4.21.4
ESP8266_797742/Milight/Remote/Counter 33
ESP8266_797742/Milight/Remote/Type B0
ESP8266_797742/Milight/Remote/Address 382C
ESP8266_797742/Milight/Remote/Command C4.21.3
ESP8266_797742/Milight/Remote/Counter 33
ESP8266_797742/Milight/Remote/Type B0
ESP8266_797742/Milight/Remote/Address 382C
ESP8266_797742/Milight/Remote/Command 3D.21.F
ESP8266_797742/Milight/Remote/Counter 33
ESP8266_797742/Milight/Remote/Type B0
ESP8266_797742/Milight/Remote/Address 382C
ESP8266_797742/Milight/Remote/Command 3D.21.F
ESP8266_797742/Milight/Remote/Counter 33
ESP8266_797742/Milight/Remote/Type B0
ESP8266_797742/Milight/Remote/Address 382C
ESP8266_797742/Milight/Remote/Command 3D.21.F
ESP8266_797742/Milight/Remote/Counter 33
ESP8266_797742/Milight/Remote/Type B0
ESP8266_797742/Milight/Remote/Address 382C
ESP8266_797742/Milight/Remote/Command 3D.21.F
ESP8266_797742/Milight/Remote/Counter 33
ESP8266_797742/Milight/Remote/Type B0
ESP8266_797742/Milight/Remote/Address 382C
ESP8266_797742/Milight/Remote/Command 3D.21.F
ESP8266_797742/Milight/Remote/Counter 33
ESP8266_797742/Milight/Remote/Type B0
ESP8266_797742/Milight/Remote/Address 382C
ESP8266_797742/Milight/Remote/Command 3D.21.0
ESP8266_797742/Milight/Remote/Counter 33


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

Update, Version 5 im 1 Beitrag angehängt. Empfängt Milight Signale und published zum MQTT server. In FHEM ein MQTT Device angelegt und schon bekommt man alles was Milight RF mäßig los ist, mit.
Theoretisch wäre jetzt auch die andere Richtung mit MQTT kein grosser Aufwand.

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

FEHMPiDi

Hallo,

Wie ist denn der Status in diesem Projekt?
Ich habe nämlich jetzt mehr als 4 Milight Controller bei mir und würde mir jetzt ungern eine zweite bridge zulegen wenn es etwas viel besseres gibt wie dieses Projekt hier.
Ist es aber schon soweit das man es gut benutzen kann, oder ist es eher noch im Entwicklungsstadium?
Dafür fehlen mir nämlich leider die Programmierkenntnisse.

Danke
FHEM5.7@RaspPi.3|NanoCUL868-HM|NanoCUL868-Max|SDuino|DS18B20|1xHM-Sen-MDIR-WM55|   
2xHM-LC-Sw1PBU-FM|HM-LC-SW4-DR|I2C_MCP23017|2xMAX-ShutterContact|11xHM-LC-Bl1PBU-FM|CTW600|VCONTROL|1xHM-Sen-MDIR-O|2xMilight

schka17

Hi, der Sketch für das MS Gateway läuft bei mir ohne Probleme und da werde ich , wenn es keine andere Anforderungen gibt, auch weiter nichts entwickeln. Ist zur Zeit für vier simulierte Bridges ausgelegt. Der MQTT sketch läuft auch, d.h. milight HF Signale werden erkannt und als Payload an den Broker geschickt.


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

Pf@nne

Zitat von: schka17 am 09 Oktober 2016, 16:33:55
1. ich habe mal ein bischen herumgespielt und Pfanne's ESP Template eingebaut, z.b. für OTA update
http://www.s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/134-esp8266-basic-library
Das funktioniert schon nicht schlecht, nur der reboot nach dem OTA update noch nicht, muss mal schauen warum.
(openmili3_OTA_MQTT.zip)

Ich habe das hier nur überflogen....aber schau mal hier, falls das noch von Interesse ist
https://forum.fhem.de/index.php/topic,50238.msg431833.html#msg431833
Nach dem ersten seriellen Flashen musst du zwingend einen HW-Reset durchführen, danach klappt das Flashen über OTA problemlos.

Gruß
Pf@nne
FHEM auf: DS415+ (Master), Raspberry Pi 2