[GELÖST] MilightBridge & MiLightDevice mit openmilight

Begonnen von Dlay, 26 Juli 2017, 16:18:30

Vorheriges Thema - Nächstes Thema

Dlay

Hallo zusammen,

derzeit versuche ich eine MiLight FUT037 ans laufen zu bringen.

Die nötigen Hex-Codes habe ich schon mit openmilight und der Fernbedienung herausgefunden.

Jetzt habe ich das Modul MiLightDevice im RGB Pfad des Quelltexts auf meine Codes angepasst.
Das senden der Codes klappt auch fast.

MilightBridge connected einwandfrei gegen openmilight und gibt auch die gesendeten Codes vom MiLightDevice weiter.
Das Problem ist allerdings das openmilight die HEX Werte in Uppercase erwartet und entweder die Bridge oder das Device nur lowercase sendet.

Wo muss der Quellcode in welchem Modul angepasst werden damit statt 0f 2c 4e eben 0F 2C 4E gesendet wird ?

Dann würde alles laufen !!

Gruß
Dlay

Dlay

Ok ich habe da wohl noch ein grundsätzliches Problem in meiner Denkweise.

Ich hatte gedacht das direkt die Hex Codes gesendet werden.

Das wird aber anscheinend noch irgendwie umgerechnet.
Mit einem Skript zur Ansteuerung von openmilight wird offensichtlich das genau die gleiche "Umwandlung" passiert wie in den Milight.pm Modulen für fhem.

So sende ich mit dem Skript den Befehl für die Farbe grün mit "\x40\xB0\x55"
openmilight empfängt vom Skript: 18 00 0F

Ich verstehe noch nicht was da passiert aber eventuell hat ja hier jemand einen tipp..

Gruß
Dlay

Beta-User

Hi Dlay,

wenn ich es richtig verstanden habe, suchst Du eine Option, neuere MiLight-Devices zu steuern (mit längeren Codes).
Habe zwar sowas zwar nicht, aber es gab hier den Hinweis, dass es mit einem neueren Openmili-Sketch (für ESP8266) gehen könnte, dann müßten die Module gar nicht angepaßt werden.

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

Dlay

#3
Zitat von: Beta-User am 28 Juli 2017, 09:00:55
Hi Dlay,

wenn ich es richtig verstanden habe, suchst Du eine Option, neuere MiLight-Devices zu steuern (mit längeren Codes).
Habe zwar sowas zwar nicht, aber es gab hier den Hinweis, dass es mit einem neueren Openmili-Sketch (für ESP8266) gehen könnte, dann müßten die Module gar nicht angepaßt werden.

Gruß, Beta-User

Hallo Beta-User,

nein ich denke eher das die Länge der Codes schon passt. Nur die Codes also solche stimmen halt einfach nicht mit denen im Modul hinterlegten überein.

Und ich kann via openmilight -l die HEX-Strings welche die Fernbedienung aussendet sehen.
Wenn ich diese Codes aber direkt verwende kommt nichts dabei heraus.

Von daher vermute ich das an einer Stelle im Modul noch eine Umsetzung auf ein anderes Codeschema passiert. Siehe meinen zweiten Post.

Wenn ich die Stelle erklärt bekomme, oder was da überhaupt passiert, könnte ich das für mich evtl. anpassen und die richtigen Codes eintragen.

Gruß
Dlay

Dlay

So ich habe es selbst gelöst.

Jetzt läuft mein FUT037 Contoller via NRF24L01+ Modul an den GPIO Pins des Raspberrys ohne Probleme.

Letztlich ist es einfach:

Via openmilight -l (L nicht I) die Codes der Fernbedienung mitsniffen. Man braucht nur die ersten 3 HEX Werte das ist quasi der Startblock beim Senden der Codes.

Dann startet man openmilight mit den Parametern:

openmilight -m -1 XXXXXX &

Wobei XXXXXX die ersten drei gesnifften HEX Codes der Fernbedienung sind.

Dann legt man sich eine Milight-Bridge an:

define milight MilightBridge 192.168.1.207:8891

Die IP müsst ihr natürlich durch eure eigene ersetzen, der Port bleibt gleich.

Und noch ein passendes MilightDevice mit:

define milight_WZ MilightDevice RGBW MilightBridge 5

Im Fall des FUT037 ruhig das RGBW nehmen, obwohl das Modul nur RGB kann. Mit RGB hat es bei mir nicht funktioniert.

Zusätzlich waren bei mir dann noch die Farben Rot und Grün vertauscht. Dafür habe ich im Modul 31_MilightDevice.pm einfach an dieser Stelle die Farbcodes vertauscht:

  my $devRed = 96; # (0xB0)
  #my $devYellow = 128; # (0x80)
  my $devYellow = 144;
  my $devGreen = 176; # (0x60)


Also 96 mit 176. Danach funktioniert alles einwandfrei.
Die Änderung am Modul würde bei jedem Update überschrieben werden, daher muss man noch ein:
attr global exclude_from_update 31_MilightDevice.pm
einfügen damit das Modul vom Update ausgeschlossen wird. (Wie gesagt nur bei Änderungen bzgl. z.B. der Farbe im Quellcode)

Das openmilight welches ich verwendet habe ist dies:

https://github.com/mattwire/openmilight_pi

Bei Fragen meldet euch gern.