Da ich imme wieder mal Problem mit diesen instabilen Dingern hatte und ausserdem die Limitierung von 4 Gruppen bestand, ersteze ich meine Milight Bridges jetzt durch einen ESP8266, der Einfachheit halber mit dem mySensor Wlan von Hexenmeister....
Den ersten Test mit einer nodemcu und NRF2401 hat funktioniert, auch das flashen des mysensor boards(musste mir gleich eins nachbestellen).
Die Original Source von Enryk Plötz (openmili Projekt) https://github.com/henryk/openmili (https://github.com/henryk/openmili) bekam ich nicht ans laufen, musste ein paar Teile ändern. Code ist attached (openmili_4_MS_GW.zip).
Ich steuere meine milight bulbs mit dem WifiLight Modul, da man auch das Port konfigurieren kann kann ich jetzt mit dieser Version 4 Milight Bridges erstezen und mit einem ESP 16 Gruppen steuern, habe zwar noch nicht so viele aber das wird schon.
Damit war eigentlich mein Ziel mal erreicht, aber
der Modulautor von WifiLight, Jörg, hat aber dann gleich ein paar Ideen losgelassen, mal schauen was man davon verwirklichen kann. https://forum.fhem.de/index.php/topic,18958.msg500460.html#msg500460 (https://forum.fhem.de/index.php/topic,18958.msg500460.html#msg500460)
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 (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 verwende keine FB's aber scheinbar gibt es Bedarf die Zustände an FHEM zurückzumelden wenn per FB geschalten wird?
Ich habe da auch ein paar Projekte gefunden (Mein Motto ist, Warum das Rad nochmal erfinden :-) )
Einmal ein Projekt mit dem Raspberry und NRF2401 von Torsten Tränkner http://torsten-traenkner.de/wissen/smarthome/openmilight.php (http://torsten-traenkner.de/wissen/smarthome/openmilight.php)
Das war schnell mal nachgebaut, also auch damit könnte man die original Bridge ersetzen, ich habs mal nur zum sniffen verwendet.
Möglicherweise noch interessanter das Projekt von Dirk Heinke https://github.com/DirkHeinke/arduino-milight-receiver (https://github.com/DirkHeinke/arduino-milight-receiver), nämlich einen Arduino als Coprozessor am LaCrosseGateway oder per USB am FHEM Server, damit ist auch senden und empfangen möglich, und das dann auch ohne UDP.
So, jetzt ersetze ich mal milight Bridges und beobacht mal wie stabil das ehemalige mysensorGW läuft.
20161228: Update, Pula hat einen Openmili Ethernet sketch entwickelt, habe ich hier hochgeladen.
ZitatSketch für Ethernet-Bridge (W5100-shield) ist fertig.
Werde ihn schka17 schicken und ihn bitten, den im 1. Beitrag anzuhängen...
Funktioniert bei mir in fhem mit wifilight und milight parallel (getestet momentan mal mit einer RGBW-Birne).
Achtung - damit das funktioniert, muß in der MyConfig.h
Code: [Auswählen]
#define SOFTSPI
gesetzt sein!!!!
Pin-Belegung im Sketch.
Cheers,
Pula
Gute Arbeit! Wer hätte gedacht, wofür man das MySensors-Gateway so alles einsetzen kann ;D
Bin gespannt, was sich alles noch realisieren lässt.
Gibt es Änderungswünsche bezüglich Hardware? Gibt es Interessenten, so dass eine neue PCB-Bestellung fällig wird?
Also aus meiner Sicht gibts da an der HW nichts zu ändern, zumindest so weit ist ich das bis jetzt einschätzen kann. Auf der SW Seite siehts da schon anders aus, da gibts noch etwas Optimierungspotential.
Btw, das WifiLight Modul unterstützt zwar die Konfiguration von unterschiedlichen Ports, leider aber nur vier Devices pro IP Adresse, ich hoffe Dass man das im Modul vielleicht änder kann.
Zitat von: schka17 am 09 Oktober 2016, 16:33:55
Ich verwende keine FB's aber scheinbar gibt es Bedarf die Zustände an FHEM zurückzumelden wenn per FB geschalten wird?
Hallo schka17,
das ist eine super interessante Sache, die Du da angeschoben hast, die doofen UDP-Bridges rauszubekommen, hatte ich irgendwie auch auf meiner längerfristigen Agenda, ebenso den Update von FHEM, wenn jemand doch versehentlich denkt, eine Fernbedienung ist einfacher zu handhaben als das Handy. Von daher hatte ich mir die Milight-API und die diversen Projekte rund um openmili auch mal angekuckt.
Da ich die Bridges (ich habe deren 4, alle definiert als MilightBridge) stark in Verdacht habe, dass die mir mit der UDP-Technik das System insgesamt immer wieder ausbremsen, wollte ich zum einen davon weg und zum anderen auch einen transparenten Rückweg haben. Damit käme eher was in Frage, das mit FHEM zusammen bidirektional arbeitet wie MySensors oder MQTT.
Allerdings sind weder die Module Wifilight noch Milight-Bridge dafür ausgelegt, oder? Wäre es nicht einfacher, ein 3. I/O-Modul mit Milight-Device zu kombinieren, und für dieses statt des slots eine Pseudo-FB-ID zu verwenden? Dann würde nicht die Sende-Node diese ID auf Basis des genutzten slots generieren, sondern den gesamten Befehl von FHEM auf einen Rutsch empfangen und ggf. wieder zurückgeben.
Technisch könnte es so gehen, dass man die Sende/Empfangsnode als MySensors-WLAN-GW (ohne MS-typischen Sender!) konfiguriert und das entsprechende Empfangs-Event dann splittet in den "Fernbedienungs-ID-Teil" und den dann aktuellen Status des Devices.
Also z.B. für den Sende-Teil so:
define Milight_Transparente_Bruecke MILIGHT_BRIDGE_ESP <IP:Port>
define Milight_Licht MilightDevice <devType(RGB|RGBW|White)> Milight_Transparente_Bruecke <slot, z.B. B0F2EA>
Na ja, klingt auch nicht gerade einfach...
Gruß,
Beta-User
Hallo Beta-User,
Tja, daher kam mein "Eigentlich", ich fürchte fast da wird mehr draus.
Ich bin mir noch nicht sicher was der richtige Weg wäre, daher freue ich mich über die Diskussion.
ZitatDa ich die Bridges (ich habe deren 4, alle definiert als MilightBridge) stark in Verdacht habe, dass die mir mit der UDP-Technik das System insgesamt immer wieder ausbremsen, wollte ich zum einen davon weg und zum anderen auch einen transparenten Rückweg haben. Damit käme eher was in Frage, das mit FHEM zusammen bidirektional arbeitet wie MySensors oder MQTT.
Da muss ich dir zustimmen, das das System bei vielen Transition sehr zäh wird, das merke ich vor allem beim Abdrehen des Multimediasystems wenn alle Milights runtergefahren werden, da gehts im Netzwerk schon ziemlich zu, dann auch im RF Bereich, und wenn ich es richtig verstanden im blocking modus.
ZitatAllerdings sind weder die Module Wifilight noch Milight-Bridge dafür ausgelegt, oder? Wäre es nicht einfacher, ein 3. I/O-Modul mit Milight-Device zu kombinieren, und für dieses statt des slots eine Pseudo-FB-ID zu verwenden? Dann würde nicht die Sende-Node diese ID auf Basis des genutzten slots generieren, sondern den gesamten Befehl von FHEM auf einen Rutsch empfangen und ggf. wieder zurückgeben.
Genau, zur Zeit ist das WifiLight Modul nicht für bidirektional Kommunikation ausgelegt, die Bridge sowieso nicht.<Fantasiemodus>das könnte man eben relativ leicht über einen daemon lösen der die FHEM Objekte updated ohne ins Modul einzugreifen, man benötigt dafür nur das mapping FB ID zu FHEM Device </Fantasiemodus>.
es gibt ja auch ein mysensor Projekt das Ausbaupotential hat https://forum.mysensors.org/topic/3607/mi-light-controller-for-mysensors (https://forum.mysensors.org/topic/3607/mi-light-controller-for-mysensors)
Ich möchte allerdings auf den Komfort den mir das WifiLight Modul bietet, nicht verzichten.
Und zuletzt dürften die erforderlichen Programmierkentnisse über adaptieren und zusammenkopieren von Codeteilen hinausgehen, mal schauen was geht...
vg
Karl
Zitat von: schka17 am 10 Oktober 2016, 11:31:19
Und zuletzt dürften die erforderlichen Programmierkentnisse über adaptieren und zusammenkopieren von Codeteilen hinausgehen, mal schauen was geht...
Hi Karl,
dann sind wir schon 2...
Zitat von: schka17 am 10 Oktober 2016, 11:31:19
es gibt ja auch ein mysensor Projekt das Ausbaupotential hat https://forum.mysensors.org/topic/3607/mi-light-controller-for-mysensors (https://forum.mysensors.org/topic/3607/mi-light-controller-for-mysensors)
Das war mir im Kopf, als ich den "Umbau" des WLAN-GW vorgeschlagen habe. Damit haette man ein quasi-serielles Protokoll und auch schon den Rueckweg, einfach ein notify auf das entsprechende reading (IR-Sensor?) der 0-Node legen und damit den split und update des eigentlichen Ziel-states machen, muesste doch gehen.
Was den Komfort angeht, kenne ich den Unterschied von Wifiligt und MilightDevice nicht. Ich mache eigentlich nur an&aus und heller bzw. dunkler, das reicht mir schon :). Gross duerfte er nicht sein, ist wohl ein fork. Qualitativ kann ich nicht beurteilen, was besser ist, es war eher Zufall, dass ich damals das genommen habe. Die Trennung zwischen Device und Bridge hat halt den Vorteil, dass man die Bridge leichter durch ein anderes logisches IO-Device ersetzen kann, daher erscheint es mir einfacher und man kann sich an der Syntax orientieren.
Schau'n wir mal...
Hallo Beta-User
da schau her, Milightbridge und MilightDevice kannte ich gar nicht, man lernt doch nie aus....
damit kannst du aber theoretisch schon mal deine 4 Milight Bridges gegen 1 nodemcu oder 1 WlanMSGW austauschen.
Habs mal ausprobiert, 4 Bridges mit der selben IP aber unterschiedlichen Ports -> funktioniert. Habe dann ein Device auf die unterschiedlichen bridges konfiguriert, zumindest im RF Bereich schaut das alles sehr gut aus (ich habe leider nicht genug Lampen um das damit auszuprobieren, zumal das unpairen noch nicht funktioniert).
ZitatWas den Komfort angeht, kenne ich den Unterschied von Wifiligt und MilightDevice nicht. Ich mache eigentlich nur an&aus und heller bzw. dunkler, das reicht mir schon :). Gross duerfte er nicht sein, ist wohl ein fork. Qualitativ kann ich nicht beurteilen, was besser ist, es war eher Zufall, dass ich damals das genommen habe. Die Trennung zwischen Device und Bridge hat halt den Vorteil, dass man die Bridge leichter durch ein anderes logisches IO-Device ersetzen kann, daher erscheint es mir einfacher und man kann sich an der Syntax orientieren.
Da stimme ich dir zu, ist auch für meine Zweck gleichwertig, allerdings blicke bei den Statis im MilightDevice nicht ganz durch.
Wenn ich dann jetzt herausfinden würde wie ich das auf ein MQTT Topic publishen kann, dann hätte ich mal die Rohdaten zum Auswerten in FHEM...
MQTT einfach deswegen, weil ich das verwende und dann nicht noch einen zusätzlichen Daemon brauche.
# OpenMiLight Receiver/Transmitter starting openmili4_OTA_MQTT<\r><\n>
### MQTT has disconnected...<\r><\n>
Connecting to MQTT-Broker: 192.168.255.9:1883<\r><\n>
MQTT connected<\r><\n>
<\r><\n>
B0 38 2C 10 BA 05 24 ...<\r><\n>
B0 38 2C 10 BA 06 25 .......
das war Lampe einschalten und Lampe ausschalten auf der Fernbedienung.
ZitatDas war mir im Kopf, als ich den "Umbau" des WLAN-GW vorgeschlagen habe. Damit haette man ein quasi-serielles Protokoll und auch schon den Rueckweg, einfach ein notify auf das entsprechende reading (IR-Sensor?) der 0-Node legen und damit den split und update des eigentlichen Ziel-states machen, muesste doch gehen.
Da kann ich dir jetzt nicht ganz folgen, meine Idee war, so eine Art Receiver für die Rückmeldung, die ist aber nur für die Fernbedienungen relevant, das was aus FHEM gesendet wird ist ja bekannt, ob das bei der Lampe ankommt kann sowieso nicht überprüft werden, man kann nur erkennen was gesendet wurde.
vg Karl
Zitat von: schka17 am 10 Oktober 2016, 14:23:07
damit kannst du aber theoretisch schon mal deine 4 Milight Bridges gegen 1 nodemcu oder 1 WlanMSGW austauschen.
Super-Sache, das! 8) Das werde ich vermutlich zeitnah in Angriff nehmen, die Bridges nerven wirklich ungemein...
Zitat von: schka17 am 10 Oktober 2016, 14:23:07
Wenn ich dann jetzt herausfinden würde wie ich das auf ein MQTT Topic publishen kann, dann hätte ich mal die Rohdaten zum Auswerten in FHEM...
MQTT einfach deswegen, weil ich das verwende und dann nicht noch einen zusätzlichen Daemon brauche.
Ich hatte zwischenzeitlich auch die diversen Quellen nochmal durchgeschaut, allerdings bin ich mit MQTT nicht vertraut.
Aber folgendes:
Vor einiger Zeit habe ich mit jemandem hier eine transparente IR-Brücke für unterschiedliche Fernbedienungssignale auf MySensors-Basis gebastelt. Da gings im Prinzip um was ähnliches, nämlich lauschen, warten bis was kommt, senden an Controller bzw. empfangene Codes in IR-Form versenden.
Daher habe ich eben versucht, ein "MySensors"-GW zu basteln, das dann aber kein klassisches MYSensors-NRF mehr kann:
Nämlich copy paste aus den drei Sketchen:
- https://github.com/brunkj/MySensorsMiLight für das Senden
- https://github.com/DirkHeinke/arduino-milight-receiver
- https://github.com/rejoe2/Mysensors-IR
Ergebnis findet sich hier, allerdings komplett ungetestet ;): https://github.com/rejoe2/MySensorsMiLight/blob/master/MilightGateway.ino
Wenn es funktioniert :-\, sollte es auch kein größeres Problem sein, das "normale" MQTT-GW aus MySensors in ähnlicher Form umzubasteln, und damit dann jegliche Mengenbeschränkung und udp rauszuwerfen...
Allerdings hätten wir dann gar kein Bridge-Modul mehr; vielleicht kannst Du auch beide Wege kombinieren (MilightDevice->Dein ESP-Sender und diesen gleichzeitig als MQTT-Broker für empfangene Codes nutzen).
Wie gesagt, super Sache bis dahin!
ZitatAllerdings hätten wir dann gar kein Bridge-Modul mehr; vielleicht kannst Du auch beide Wege kombinieren (MilightDevice->Dein ESP-Sender und diesen gleichzeitig als MQTT-Broker für empfangene Codes nutzen).
genau das ist jetzt mal der Plan, daher habe ich das Template von Pfanne verwendet für OTA, MQTT usw. Tut auch soweit schon mal, mir fehlt nur der Link wie ich die empfangenen Date als Payload publishen kann.
Zitat von: schka17 am 10 Oktober 2016, 16:11:16
genau das ist jetzt mal der Plan, daher habe ich das Template von Pfanne verwendet für OTA, MQTT usw. Tut auch soweit schon mal, mir fehlt nur der Link wie ich die empfangenen Date als Payload publishen kann.
Wie gesagt, mit MQTT kenn ich mich praktisch gar nicht aus. Aber an sich ist es immer kein großer Unterschied, ob man irgendwelche Werte an der seriellen Schnittstelle raushaut oder sie via (Mysensors ....)-Funkprotokoll sendet. Der Schritt zum Publish bzw. Push auf einen Broker ist sicher auch nicht größer, wenn man den "Sende"-Mechanismus verstanden hat.
Kannst Du den Link auf auf die von Dir genannten Templates usw. mal posten? Vielleicht kann ich dann zum MQTT-Publish doch was beitragen.
Dazu sollte ich aber noch wissen, ob der Sensor/ESP gleichzeitig auch Broker sein soll (so hatte ich das verstanden). Dann müßte es bei MySensors in dem ESP-GW-Broker-Sketch die "Bausteine" geben... EDIT: das scheint gar nicht zu gehen, die ESP's sind in der Regel nur Clients, man braucht einen seperaten Server (kann auch dieselbe Maschine wie für den FHEM-Server sein). Aber zum publish steht tatsächlich einiges in den MySensors-Sourcen.
Ach ja, der Sketch für ein modifizierten "GW" würde mich natürlich auch interessieren (als 4x4-fach-Sender) 8)
Lesen macht schlau, war unten schon dabei, sorry...
Zitat von: schka17 am 10 Oktober 2016, 14:23:07zumal das unpairen noch nicht funktioniert).
Das ist nach meiner Erinnerung doch auch nur wieder ein einfacher "On"-Befehl gleich nach dem Einschalten der Spannung. Die Birnen blinken beim unpair einfach öfter... Oder habe ich das Problem nicht verstanden?
Off-Topic für Eingeweihte: Ich bin auf dem besten Weg, mich mit dem ESP zu versöhnen (aber nur, weil die Milight-Bridges noch bescheuertere HW sind bzw. das Programm mies ist, was auf den dort verbauten läuft) ::)...
:D :D :D
Man kann es nicht besser sagen !
Zitat von: herrmannj am 10 Oktober 2016, 17:52:34
:D :D :D
Man kann es nicht besser sagen !
ich glaub', ich will besser keine nähere Ausführung, was "es" konkret bedeutet ::)
die sketches hast du ja gefunden, der fürs MSGW läuft auf Hexenmeisters Board.
Das mit dem unpairen ist so eine Sache, ja sollte laut Beschreibung so funktionieren, das WifiLght Modul macht das auch, aber es funktioniert nicht. Es funktioniert auch auf der FB nur mit der 2.Methode, den ON Key der entsprechenden Gruppe 5s drücken, dann ist aber die Sequenz die gesendet wird eine andere. habe ich im WifiLight threat beschrieben. Das ist natürlich etwas blöd zum testen wenn ich die Bulbs nicht unpairen kann....
...ja ja, wer suchet, der findet...
Leider kann ich das im Moment nicht testen, weil mir vorhin die HDD abgeraucht ist, und seit gestern meine seriellen GW's dauernd neustarten, anstatt ein Connect zu liefern, das wird also dauern...
Das mit dem unpair habe ich aber noch mit einer der Milight-Bridges getestet, und die kennen keine dauernd gedrückten Tasten: pairen und unpairen geht bei denen nicht mit "on", sondern mit (MilightDevice) "set Licht_Flur rgb ffffff", also Reinweis.
Viel Spaß beim Testen
Zitat von: Beta-User am 10 Oktober 2016, 21:10:04
...ja ja, wer suchet, der findet...
Leider kann ich das im Moment nicht testen, weil mir vorhin die HDD abgeraucht ist, und seit gestern meine seriellen GW's dauernd neustarten, anstatt ein Connect zu liefern, das wird also dauern...
Das mit dem unpair habe ich aber noch mit einer der Milight-Bridges getestet, und die kennen keine dauernd gedrückten Tasten: pairen und unpairen geht bei denen nicht mit "on", sondern mit (MilightDevice) "set Licht_Flur rgb ffffff", also Reinweis.
Viel Spaß beim Testen
Beim pairen stimmt das, die on tasten auf der Fernbedienung entspricht schalte weiss 100%, oder wie auch immer das im Modul umgesetzt ist. Im RF Protokoll wird die On Taste der jeweiligen Gruppe gesendet, also 3,5,7 oder 9.
Beim unpairen, ich spreche jetzt von der offiziellen Beschreibung mit der Fernbedienung oder App, gibt es zwei Methoden, entweder 5x die On Taste (das funktioniert bei meinen Bulbs nicht) oder die On-Taste länger gedrückt halten, das funktioniert. Im RF Bereich unterscheiden sich diese beiden Prozeduren. Im WifiLight ist die erste Variante implementiert, die RF Sequenz erzeugt die selbe Sequenz wie die Fernbedienung, geht halt bei mir nicht.jetzt habe ich halt leider beim Testen ein paar Lampen gepairt und krieg sie nicht mehr weg. Ich habe gesehen beim Milight Device gibt es auch pair und unpair, ich habs aber noch nicht damit ausprobiert.
Sent from my iPad using Tapatalk
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
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...
@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
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
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...
Ja korrekt. Milight sollte immer am netz sein. Ansonsten ist frust vorprogrammiert
Vg
Joerg
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 (https://community.openhab.org/t/mqtt-ir-transmiter-receiver/9433) 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
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 (https://community.openhab.org/t/mqtt-ir-transmiter-receiver/9433) 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
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...
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
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
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.
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
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
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 (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 (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
Zitat von: Pf@nne am 18 November 2016, 10:01:48
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 (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
Ich bilde mir ein das dass genauso war, aber eigentlich nur während der Entwicklung interessant, Wirklich wichtig ist es mir im Echtbetrieb nicht, einmal geflasht läufts ja, und in nächster Zeit sehe ich keinen Bedarf für Erweiterungen.
Danke jedenfalls für das Template das hat einiges erleichtert.
Ich bekomme das nicht mal kompiliert. Was muss man denn dazu alles nachinstallieren damit es geht?
Moin,
das Basic_Template?
Zitat von: Bapt. Reverend Magersuppe am 19 November 2016, 19:23:59
Ich bekomme das nicht mal kompiliert. Was muss man denn dazu alles nachinstallieren damit es geht?
Wenn du den MQTT sketch meinst, dann habe ich nur Pfannes Template benutzt und das basic data.cpp geändert. Das ganze mit Arduino 6.1.12.
Sent from my iPad using Tapatalk
Zitat von: schka17 am 19 November 2016, 22:44:17
Wenn du den MQTT sketch meinst, dann habe ich nur Pfannes Template benutzt und das basic data.cpp geändert. Das ganze mit Arduino 6.1.12.
Sent from my iPad using Tapatalk
So hatte ich das auch verstanden, deswegen verstehe ich gar nicht warum das nicht geht. Alles in einem Verzeichnis ausgepackt, das openMili5-ino angetickt und Arduino öffnet sich. Drückt man auf das Kompilat bekomme ich:
Documents\Arduino\openmili5_OTA_MQTT\openmili5_OTA_MQTT.ino:2:22: fatal error: nRF24L01.h: No such file or directory
Dabei liegt die nRF24L01.h genau da in dem Verzeichnis mit drin! Die Software (Arduino 1.6.12) will mich doch veräppeln!
Zitat von: Bapt. Reverend Magersuppe am 20 November 2016, 12:05:33
So hatte ich das auch verstanden, deswegen verstehe ich gar nicht warum das nicht geht. Alles in einem Verzeichnis ausgepackt, das openMili5-ino angetickt und Arduino öffnet sich. Drückt man auf das Kompilat bekomme ich:
Documents\Arduino\openmili5_OTA_MQTT\openmili5_OTA_MQTT.ino:2:22: fatal error: nRF24L01.h: No such file or directory
Dabei liegt die nRF24L01.h genau da in dem Verzeichnis mit drin! Die Software (Arduino 1.6.12) will mich doch veräppeln!
Mich bringt die Arduino IDE auch immer zum verzweifeln, ich habe es als Portable installiert da ich mehrere Umgebungen verwende. Ich habe hier mal ein paar Bilder der Ordnerstruktur, vielleicht hilft dir das
Moin,
ich hab mir jetzt auch 2 Milights bestellt. Muß ich die ESPBridge irgendwie mit den Bulbs pairen?
// bb
Zitat von: bloodybeginner am 30 November 2016, 13:41:48
Moin,
ich hab mir jetzt auch 2 Milights bestellt. Muß ich die ESPBridge irgendwie mit den Bulbs pairen?
// bb
Ja, genauso wie die original Bridge.
Sent from my iPad using Tapatalk
Zitat von: schka17 am 20 November 2016, 18:44:29
Mich bringt die Arduino IDE auch immer zum verzweifeln, ich habe es als Portable installiert da ich mehrere Umgebungen verwende. Ich habe hier mal ein paar Bilder der Ordnerstruktur, vielleicht hilft dir das
Halleluja! Vielen Dank für Deine Unterstützung!
Zumindest habe ich es jetzt kompiliert bekommen.
Also:
Erstmal Pfannes Basic ins Lib-Verzeichnis, hier dann die ESP8266_Basic_data.cpp aus dem Milight-Verzeichnis reinkopieren.
Dann erstmal "Überprüfen" im Arduino drücken und orgeln lassen. Jetzt müssen einige Libs über den Library-Manager nachinstalliert werden, je nachdem wie viel man vorher schon gemacht hat.
Weiter gehts.
Hallo,
wäre es möglich eine Art Anleitung zu schreiben was man braucht und was man machen muss?
Ich würde mir das nämlich gern nachbauen, blicke aber noch nicht so ganz durch.
Ich brauche also das mysensor wlaninterface von Hexenmeister, richtig? Was muss ich dann wie weiter machen?
Danke
Gesendet von meinem SM-G901F mit Tapatalk
Zitat von: FEHMPiDi am 01 Dezember 2016, 14:13:27
Hallo,
wäre es möglich eine Art Anleitung zu schreiben was man braucht und was man machen muss?
Ich würde mir das nämlich gern nachbauen, blicke aber noch nicht so ganz durch.
Ich brauche also das mysensor wlaninterface von Hexenmeister, richtig? Was muss ich dann wie weiter machen?
Danke
Gesendet von meinem SM-G901F mit Tapatalk
Hallo,
ganz klares Jein.
Das Mysensor Gateway von Hexenmeister ist die ideale HW Basis, aber du kannst auch einfach einen ESP NodeMCU Devkit oder Wemos Mini etc. und einen NRF zusammenstecken (nícht mal löten notwendig) wie auf der mysensor Seite beschreiben:
https://www.mysensors.org/build/esp8266_gateway (https://www.mysensors.org/build/esp8266_gateway)
Dann das Openmili MS Package runterladen und in die Arduino IDE kopieren (in den ordner mit den Libraries). Ich arbeite zur Zeit mit Arduino 1.6.12.
Dann die Arduino IDE starten, openmili_4_MS_GW.ino öffnen, die HW Platform und Port auswählen, kompilieren und uploaden.
Thats It.
Gruß
Karl
Ok, ich werde es mal versuchen wenn ich die Hardware habe.
Danke für die Anleitung.
Gesendet von meinem SM-G901F mit Tapatalk
Ich wollte meine 3 Lampen auch über FHEM Steuern und bin auf das Projekt gestoßen :D
Leider zeigt bei mir das Device nichts an, habe auf der Seriellen Konsole geschaut. Den Scanner im Beispiel Ordner habe ich mal über einen Arduino gebaut, der hat funktioniert.
Sollte über die Serielle Konsole oder MQTT bei den sketch nicht das empfangene von der Fernbedienung kommen ?
Thx
Zitat von: Maiks am 05 Dezember 2016, 22:21:36
Ich wollte meine 3 Lampen auch über FHEM Steuern und bin auf das Projekt gestoßen :D
Leider zeigt bei mir das Device nichts an, habe auf der Seriellen Konsole geschaut. Den Scanner im Beispiel Ordner habe ich mal über einen Arduino gebaut, der hat funktioniert.
Sollte über die Serielle Konsole oder MQTT bei den sketch nicht das empfangene von der Fernbedienung kommen ?
Thx
Ja, auf der seriellen Schnittstelle sieht man genau was abläuft. Welche Baudrate hast du eingestellt?
Sent from my iPad using Tapatalk
Hallo,
wollte heute meine NodeMCU mit Arduino IDE(1.6.8) flashen, bekomme aber einen Fehler:
sketch\PL1167_nRF24.h:13:18: fatal error: RF24.h: No such file or directory
Die RF24.h ist überhaupt nicht in der"openmili_4_MS_GW" vorhanden.
Wo bekomme ich sie her, oder was muss ich machen?
Gruß
Daniel
Ja, da war was, ist jetzt schon eine Zeit her, aber meine diese Library musste ich auch nachinstallieren. Ich kann mich aber nicht mehr erinnern ob ich das über library management gemacht habe oder runtergeladen und reinkopiert. Wenn du den library manager öffnest, kannst du dort mal nach NRF24 suchen?
Sent from my iPad using Tapatalk
Ja die LIbary geht über den Manager RF24 eingeben und dann die RF24 Libary auswählen ;)
Jetzt zu meinem Problem, ich sehe schon, das dass device gestartet ist über die Serielle konsole im Klartext, allerdings kommt kein Kommando meiner Fernbedienung an wenn ich eine Taste drücke (MQTT oder Seriell) nichts zu sehen :(
Kann es sein, das mein Protokoll nict kompatibel ist, da ich eine RGBWW Lampe habe und nicht nur RGB ?
Danke für die Antwort. Habe es gefunden.
Aber ich musste noch einige Liberies nachintallieren bis es endlich klappte. ;D
Hallo Maiks,
Das kann ich ausschließen, ich habe auch einige RBGWW Lampen. Hast du mal probiert eine milightbridge anzulegen und schauen ob du die Lampe aus FHEM steuern kannst?
Sent from my iPad using Tapatalk
Zitat von: Maiks am 06 Dezember 2016, 17:58:52
Jetzt zu meinem Problem, ich sehe schon, das dass device gestartet ist über die Serielle konsole im Klartext, allerdings kommt kein Kommando meiner Fernbedienung an wenn ich eine Taste drücke (MQTT oder Seriell) nichts zu sehen :(
Kann es sein, das mein Protokoll nict kompatibel ist, da ich eine RGBWW Lampe habe und nicht nur RGB ?
Die Fernbedienung weiss ja nichts davon, die sendet nur die Codes für die Lampe. Geht dein NRF denn auf Empfang?
Gibt es eigentlich eine Möglichkeit zu probieren ob der NRF funktioniert?
Hallo
Hab jetzt auch meine NodeMCU fertig gemacht! Habe Ihn auch per "define MiLightBridge2 MilightBridge 192.168.0.25" in fhem definiert!
Aber wie bekomme ich jetzt die LED Controller gepairt? Habe es damit versucht "define Testlampe MilightDevice RGBW MiLightBridge2 5" aber die LEDs reagieren nicht.
Muß ich die erst vom der Originalen Bridge entpairen?
Bin nicht ganz so fit in der Sache.
Vielleicht kann mir da jemand weiterhelfen.
Gruß
Du must die Bulbs mit der Bridge pairen, wie bei den orginalen Bridges oder Fernbedienungen auch (vgl. die Posts um #17 herum an).
Also: Strom für das Leuchtmittel abschalten, dann Strom an+ganz kurzfristig irgendeinen Schaltbefehl, am besten "on".
Gruß,
Beta-User
Danke,
jetzt funktioniert alles.
Mal testen ob die Bridge jetzt stabiler läuft.
Gruß Daniel
Hab jetzt doch noch ein Problem!
Ich habe 3 Bulbs(2xRGBW u. 1xRGB). Alle lassen sich einzeln per Fhem regeln.
Aber wenn ich den RGB-Bulb auf eine Farbe eingestellt habe und dann einen bestimmten RGBW-Bulb ansteuere geht der RGB-Bulb auf Weiß, nur auf Weiß. Keine andere Farbe.
In Fhem ändert sich nichts.
Woran kann das liegen. Das macht der mit der alten Bridge nicht!
Nun, mit den mitgeteilten Informationen würde ich jetzt mal vermuten, da stimmt was nicht.
Also mit ein paar mehr Informationen wie z.b. list der devices, log mit verbose 5, Output der seriellen Schnittstelle, und ganz high sophisticated, mit einem Netzwerk Protokoll könnte man das analysieren.
Gruß
Karl
Habe mit dem MSGW4 mal ausprobiert eine Lampe zu pairen, da geht auch nicht. Gehe nach dem Einschalten auf on aber es passiert nichts. Log vom ESP sieht so aus.
Deffiniert habe ich es so (RGBW bridge-V3:192.168.0.86)
Angeschlossen habe ich es wie im Sketch angegeben und auch x mal kontrolliert :(
Ist echt zum .........
Contents: 45 0 55 <\r><\n>
Write : B0 63 D2 0 81 3 14 <\r><\n>
................<\r><\n>
Contents: C5 0 55 <\r><\n>
Write : B0 63 D2 0 81 13 15 <\r><\n>
...<\r><\n>
Contents: 4E 1B 55 <\r><\n>
Write : B0 63 D2 0 B9 E 16 <\r><\n>
................<\r><\n>
Contents: 45 0 55 <\r><\n>
Write : B0 63 D2 0 B9 3 17 <\r><\n>
................<\r><\n>
Contents: C5 0 55 <\r><\n>
Write : B0 63 D2 0 B9 13 18 <\r><\n>
..<\r><\n>
Contents: 4E 1B 55 <\r><\n>
Write : B0 63 D2 0 B9 E 19 <\r><\n>
................<\r><\n>
Contents: 45 0 55 <\r><\n>
Write : B0 63 D2 0 B9 3 1A <\r><\n>
................<\r><\n>
Contents: C5 0 55 <\r><\n>
Write : B0 63 D2 0 B9 13 1B <\r><\n>
..<\r><\n>
Contents: 4E 1B 55 <\r><\n>
Write : B0 63 D2 0 B9 E 1C <\r><\n>
................
Zitat von: Maiks am 08 Dezember 2016, 20:44:47
Habe mit dem MSGW4 mal ausprobiert eine Lampe zu pairen, da geht auch nicht. Gehe nach dem Einschalten auf on aber es passiert nichts. Log vom ESP sieht so aus.
Deffiniert habe ich es so (RGBW bridge-V3:192.168.0.86)
Angeschlossen habe ich es wie im Sketch angegeben und auch x mal kontrolliert :(
Ist echt zum .........
Contents: 45 0 55 <\r><\n>
Write : B0 63 D2 0 81 3 14 <\r><\n>
................<\r><\n>
Contents: C5 0 55 <\r><\n>
Write : B0 63 D2 0 81 13 15 <\r><\n>
...<\r><\n>
Contents: 4E 1B 55 <\r><\n>
Write : B0 63 D2 0 B9 E 16 <\r><\n>
................<\r><\n>
Contents: 45 0 55 <\r><\n>
Write : B0 63 D2 0 B9 3 17 <\r><\n>
................<\r><\n>
Contents: C5 0 55 <\r><\n>
Write : B0 63 D2 0 B9 13 18 <\r><\n>
..<\r><\n>
Contents: 4E 1B 55 <\r><\n>
Write : B0 63 D2 0 B9 E 19 <\r><\n>
................<\r><\n>
Contents: 45 0 55 <\r><\n>
Write : B0 63 D2 0 B9 3 1A <\r><\n>
................<\r><\n>
Contents: C5 0 55 <\r><\n>
Write : B0 63 D2 0 B9 13 1B <\r><\n>
..<\r><\n>
Contents: 4E 1B 55 <\r><\n>
Write : B0 63 D2 0 B9 E 1C <\r><\n>
................
Das sieht eigentlich gut aus, kann dann dann eigentlich nur mehr am NRF liegen, ich meine das der nicht sendet, warum auch immer, hast du einen zweiten? Dann kann man mal auf 2,4 GHz sniffen.
Sent from my iPad using Tapatalk
Hallo hier sind einige Mitschnitte.
Mit high sophisticated und einem Netzwerk Protokoll kann ich nicht dienen. Keine Ahnung wie das geht.
List Devices
Backlight_LCD
Internals:
DEF RGBW MiLightBridge1 8
INIT 1
IODev MiLightBridge1
LEDTYPE RGBW
NAME Backlight_LCD
NR 1114
NTFY_ORDER 50-Backlight_LCD
SLOT 8
SLOTID 8
STATE on 100
TYPE MilightDevice
Readings:
2016-12-09 09:58:03 brightness 100
2016-12-09 09:57:52 brightness_on 100
2016-12-09 09:58:03 discoMode 0
2016-12-09 09:58:03 discoSpeed 0
2016-12-09 09:58:03 hsv 241,100,100
2016-12-09 09:58:03 hue 241
2016-12-09 09:58:03 previousState 241,100,0
2016-12-09 09:58:03 rgb 0400FF
2016-12-09 09:58:03 saturation 100
2016-12-09 09:58:03 state on 100
2016-12-09 09:58:03 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 26
colorValue 16
targetHue 241
targetSat 100
targetTime 1481273883.3733
targetVal 100
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 MiLightBridge1
devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
event-on-change-reading state,transitionInProgress
fp_Grundriss 754,55,2,BacklightTV,
lightSceneParamsToSave hsv
restoreAtStart 1
room 1.2 Wohnzimmer,MiLight
verbose 5
webCmd on:off:dim:hue:night:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffff00
FlurRGBWW
Internals:
DEF RGBW MiLightBridge1 6
INIT 1
IODev MiLightBridge1
LEDTYPE RGBW
NAME FlurRGBWW
NR 1111
NTFY_ORDER 50-FlurRGBWW
SLOT 6
SLOTID 6
STATE on 100
TYPE MilightDevice
Readings:
2016-12-09 09:59:24 brightness 100
2016-12-09 09:57:52 brightness_on 100
2016-12-09 09:59:24 discoMode 0
2016-12-09 09:59:24 discoSpeed 0
2016-12-09 09:59:24 hsv 0,0,100
2016-12-09 09:59:24 hue 0
2016-12-09 09:59:24 previousState 0,0,0
2016-12-09 09:59:24 rgb FFFFFF
2016-12-09 09:59:24 saturation 0
2016-12-09 09:59:24 state on 100
2016-12-09 09:59:24 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 1481273964.34163
targetVal 100
whiteLevel 26
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 MiLightBridge1
alias Flur Groß
devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
event-on-change-reading state,transitionInProgress
fp_Grundriss 849,55,2,Flur Groß
lightSceneParamsToSave hsv
restoreAtStart 1
room 1.1 Flur,MiLight
verbose 5
webCmd on:off:dim:hue:night:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffff00
Flur2_RGBWW
Internals:
DEF RGBW MiLightBridge1 5
INIT 1
IODev MiLightBridge1
LEDTYPE RGBW
NAME Flur2_RGBWW
NR 1110
NTFY_ORDER 50-Flur2_RGBWW
SLOT 5
SLOTID 5
STATE on 100
TYPE MilightDevice
Readings:
2016-12-09 10:00:43 brightness 100
2016-12-09 09:57:53 brightness_on 100
2016-12-09 10:00:43 discoMode 0
2016-12-09 10:00:43 discoSpeed 0
2016-12-09 10:00:43 hsv 0,0,100
2016-12-09 10:00:43 hue 0
2016-12-09 10:00:43 previousState 0,0,0
2016-12-09 10:00:43 rgb FFFFFF
2016-12-09 10:00:43 saturation 0
2016-12-09 10:00:43 state on 100
2016-12-09 10:00:43 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 1481274043.29254
targetVal 100
whiteLevel 26
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 MiLightBridge1
alias Flur Klein
devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
event-on-change-reading state,transitionInProgress
fp_Grundriss 851,655,2,Flur Klein
lightSceneParamsToSave hsv
restoreAtStart 1
room 1.1 Flur,MiLight
verbose 5
webCmd on:off:dim:hue:night:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffff00
Serial Port in Arduino IDE
Backlight_LCD (RGB) wurden 100% Blau angeschaltet
Contents: 4B 0 55
Write : B0 63 D2 AF 24 9 79
................
Contents: 40 10 55
Write : B0 63 D2 AF 4 F 7A
................
Contents: 4E 1A 55
Write : B0 63 D2 AF C4 E 7B
................
Contents: 4B 0 55
Write : B0 63 D2 AF C4 9 7C
................
Contents: 40 10 55
Write : B0 63 D2 AF 4 F 7D
................
Contents: 4E 1A 55
Write : B0 63 D2 AF C4 E 7E
................
--------------------------------------------
FlurRGBWW (RGBW) wurden 100% Weiß Angeschaltet
Contents: 47 0 55
Write : B0 63 D2 AF C4 5 7F
................
Contents: C7 0 55
Write : B0 63 D2 AF C4 15 80
................
Contents: 4E 1A 55
Write : B0 63 D2 AF C2 E 81
................
Contents: 47 0 55
Write : B0 63 D2 AF C2 5 82
................
Contents: C7 0 55
Write : B0 63 D2 AF C2 15 83
................
Contents: 4E 1A 55
Write : B0 63 D2 AF C2 E 84
................
----------------------------------------------
Flur2_RGBWW (RGBW) wurden 100% Weiß Angeschaltet
Contents: 45 0 55
Write : B0 63 D2 AF C2 3 85
................
Contents: C5 0 55
Write : B0 63 D2 AF C2 13 86
................
Contents: 4E 1A 55
Write : B0 63 D2 AF C1 E 87
................
Contents: 45 0 55
Write : B0 63 D2 AF C1 3 88
................
Contents: C5 0 55
Write : B0 63 D2 AF C1 13 89
................
Contents: 4E 1A 55
Write : B0 63 D2 AF C1 E 8A
................
Verbose 5
Backlight_LCD wurden 100% Blau angeschaltet
2016.12.09 09:58:03 4: Backlight_LCD_RGBW_On: Set ON; Ramp: 0
2016.12.09 09:58:03 4: Backlight_LCD_RGBW_Dim: Brightness: 100; Ramp: 0; Flags:
2016.12.09 09:58:03 4: Backlight_LCD_CmdQueue_Clear
2016.12.09 09:58:03 5: Backlight_LCD_HSV_Transition: Prepare Start (actual): 241,100,0@1481273883.3733
2016.12.09 09:58:03 5: MilightDevice_HSVToStr: h:241,s:100,v:0
2016.12.09 09:58:03 4: Backlight_LCD_HSV_Transition: Current: 241,100,0
2016.12.09 09:58:03 4: Backlight_LCD_HSV_Transition: Set: 241,100,100; Ramp: 0; Flags:
2016.12.09 09:58:03 4: Backlight_LCD_HSV_Transition: Set: 241,100,100; No Ramp
2016.12.09 09:58:03 4: Backlight_LCD_CmdQueue_Add: h: 241; s: 100; v: 100; Ctrl ; TargetTime: ; QLen: 1
2016.12.09 09:58:03 5: MilightDevice_RGBW_SetHSV: h:241 s:100 v:100 / cv:16 wl:0 cl:26
2016.12.09 09:58:03 5: MilightDevice_HSVToStr: h:241,s:100,v:100
2016.12.09 09:58:03 4: MiLightBridge1_Write: Command: 4b0055
2016.12.09 09:58:03 5: MiLightBridge1 send: 4b0055@1481273883.4554; Queue Length: 1
2016.12.09 09:58:03 4: MiLightBridge1_Write: Command: 401055
2016.12.09 09:58:03 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273883.45598. Now: 1481273883.45672
2016.12.09 09:58:03 4: MiLightBridge1_Write: Command: 4e1a55
2016.12.09 09:58:03 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273883.45598. Now: 1481273883.46058
2016.12.09 09:58:03 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273883.55972
2016.12.09 09:58:03 4: MiLightBridge1_Write: Command: 4b0055
2016.12.09 09:58:03 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273883.45598. Now: 1481273883.46418
2016.12.09 09:58:03 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273883.56361
2016.12.09 09:58:03 4: MiLightBridge1_Write: Command: 401055
2016.12.09 09:58:03 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273883.45598. Now: 1481273883.46761
2016.12.09 09:58:03 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273883.56701
2016.12.09 09:58:03 4: MiLightBridge1_Write: Command: 4e1a55
2016.12.09 09:58:03 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273883.45598. Now: 1481273883.47137
2016.12.09 09:58:03 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273883.57075
2016.12.09 09:58:03 5: Backlight_LCD_CmdQueue_Exec: Next Exec: 1481273883.47451
2016.12.09 09:58:03 5: MiLightBridge1 send: 401055@1481273883.58315; Queue Length: 5
2016.12.09 09:58:03 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273883.57435
2016.12.09 09:58:03 5: MiLightBridge1 send: 4e1a55@1481273883.69602; Queue Length: 4
2016.12.09 09:58:03 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273883.68723
2016.12.09 09:58:03 5: MiLightBridge1 send: 4b0055@1481273883.80865; Queue Length: 3
2016.12.09 09:58:03 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273883.80029
2016.12.09 09:58:03 5: MiLightBridge1 send: 401055@1481273883.92136; Queue Length: 2
2016.12.09 09:58:03 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273883.91258
2016.12.09 09:58:04 5: MiLightBridge1 send: 4e1a55@1481273884.0341; Queue Length: 1
FlurRGBWW wurden 100% Weiß Angeschaltet
2016.12.09 09:59:24 4: FlurRGBWW_RGBW_On: Set ON; Ramp: 0
2016.12.09 09:59:24 4: FlurRGBWW_RGBW_Dim: Brightness: 100; Ramp: 0; Flags:
2016.12.09 09:59:24 4: FlurRGBWW_CmdQueue_Clear
2016.12.09 09:59:24 5: FlurRGBWW_HSV_Transition: Prepare Start (actual): 0,0,0@1481273964.34163
2016.12.09 09:59:24 5: MilightDevice_HSVToStr: h:0,s:0,v:0
2016.12.09 09:59:24 4: FlurRGBWW_HSV_Transition: Current: 0,0,0
2016.12.09 09:59:24 4: FlurRGBWW_HSV_Transition: Set: 0,0,100; Ramp: 0; Flags:
2016.12.09 09:59:24 4: FlurRGBWW_HSV_Transition: Set: 0,0,100; No Ramp
2016.12.09 09:59:24 4: FlurRGBWW_CmdQueue_Add: h: 0; s: 0; v: 100; Ctrl ; TargetTime: ; QLen: 1
2016.12.09 09:59:24 5: MilightDevice_RGBW_SetHSV: h:0 s:0 v:100 / cv:176 wl:26 cl:0
2016.12.09 09:59:24 5: MilightDevice_HSVToStr: h:0,s:0,v:100
2016.12.09 09:59:24 4: MiLightBridge1_Write: Command: 470055
2016.12.09 09:59:24 5: MiLightBridge1 send: 470055@1481273964.42245; Queue Length: 1
2016.12.09 09:59:24 4: MiLightBridge1_Write: Command: c70055
2016.12.09 09:59:24 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273964.42322. Now: 1481273964.42385
2016.12.09 09:59:24 4: MiLightBridge1_Write: Command: 4e1a55
2016.12.09 09:59:24 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273964.42322. Now: 1481273964.42764
2016.12.09 09:59:24 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273964.52688
2016.12.09 09:59:24 4: MiLightBridge1_Write: Command: 470055
2016.12.09 09:59:24 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273964.42322. Now: 1481273964.43173
2016.12.09 09:59:24 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273964.53101
2016.12.09 09:59:24 4: MiLightBridge1_Write: Command: c70055
2016.12.09 09:59:24 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273964.42322. Now: 1481273964.43526
2016.12.09 09:59:24 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273964.5347
2016.12.09 09:59:24 4: MiLightBridge1_Write: Command: 4e1a55
2016.12.09 09:59:24 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273964.42322. Now: 1481273964.43897
2016.12.09 09:59:24 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273964.53833
2016.12.09 09:59:24 5: FlurRGBWW_CmdQueue_Exec: Next Exec: 1481273964.44225
2016.12.09 09:59:24 5: MiLightBridge1 send: c70055@1481273964.55103; Queue Length: 5
2016.12.09 09:59:24 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273964.54204
2016.12.09 09:59:24 5: MiLightBridge1 send: 4e1a55@1481273964.66342; Queue Length: 4
2016.12.09 09:59:24 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273964.65511
2016.12.09 09:59:24 5: MiLightBridge1 send: 470055@1481273964.77567; Queue Length: 3
2016.12.09 09:59:24 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273964.7673
2016.12.09 09:59:24 5: MiLightBridge1 send: c70055@1481273964.88782; Queue Length: 2
2016.12.09 09:59:24 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273964.87956
2016.12.09 09:59:25 5: MiLightBridge1 send: 4e1a55@1481273965.00582; Queue Length: 1
Flur2_RGBWW wurden 100% Weiß Angeschaltet
2016.12.09 10:00:43 4: Flur2_RGBWW_RGBW_On: Set ON; Ramp: 0
2016.12.09 10:00:43 4: Flur2_RGBWW_RGBW_Dim: Brightness: 100; Ramp: 0; Flags:
2016.12.09 10:00:43 4: Flur2_RGBWW_CmdQueue_Clear
2016.12.09 10:00:43 5: Flur2_RGBWW_HSV_Transition: Prepare Start (actual): 0,0,0@1481274043.29254
2016.12.09 10:00:43 5: MilightDevice_HSVToStr: h:0,s:0,v:0
2016.12.09 10:00:43 4: Flur2_RGBWW_HSV_Transition: Current: 0,0,0
2016.12.09 10:00:43 4: Flur2_RGBWW_HSV_Transition: Set: 0,0,100; Ramp: 0; Flags:
2016.12.09 10:00:43 4: Flur2_RGBWW_HSV_Transition: Set: 0,0,100; No Ramp
2016.12.09 10:00:43 4: Flur2_RGBWW_CmdQueue_Add: h: 0; s: 0; v: 100; Ctrl ; TargetTime: ; QLen: 1
2016.12.09 10:00:43 5: MilightDevice_RGBW_SetHSV: h:0 s:0 v:100 / cv:176 wl:26 cl:0
2016.12.09 10:00:43 5: MilightDevice_HSVToStr: h:0,s:0,v:100
2016.12.09 10:00:43 4: MiLightBridge1_Write: Command: 450055
2016.12.09 10:00:43 5: MiLightBridge1 send: 450055@1481274043.37137; Queue Length: 1
2016.12.09 10:00:43 4: MiLightBridge1_Write: Command: c50055
2016.12.09 10:00:43 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481274043.37215. Now: 1481274043.37272
2016.12.09 10:00:43 4: MiLightBridge1_Write: Command: 4e1a55
2016.12.09 10:00:43 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481274043.37215. Now: 1481274043.37629
2016.12.09 10:00:43 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481274043.47551
2016.12.09 10:00:43 4: MiLightBridge1_Write: Command: 450055
2016.12.09 10:00:43 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481274043.37215. Now: 1481274043.3801
2016.12.09 10:00:43 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481274043.47924
2016.12.09 10:00:43 4: MiLightBridge1_Write: Command: c50055
2016.12.09 10:00:43 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481274043.37215. Now: 1481274043.3837
2016.12.09 10:00:43 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481274043.4831
2016.12.09 10:00:43 4: MiLightBridge1_Write: Command: 4e1a55
2016.12.09 10:00:43 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481274043.37215. Now: 1481274043.38702
2016.12.09 10:00:43 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481274043.48648
2016.12.09 10:00:43 5: Flur2_RGBWW_CmdQueue_Exec: Next Exec: 1481274043.39018
2016.12.09 10:00:43 5: MiLightBridge1 send: c50055@1481274043.4985; Queue Length: 5
2016.12.09 10:00:43 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481274043.49004
2016.12.09 10:00:43 5: MiLightBridge1 send: 4e1a55@1481274043.61091; Queue Length: 4
2016.12.09 10:00:43 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481274043.60274
2016.12.09 10:00:43 5: MiLightBridge1 send: 450055@1481274043.72306; Queue Length: 3
2016.12.09 10:00:43 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481274043.71466
2016.12.09 10:00:43 5: MiLightBridge1 send: c50055@1481274043.83494; Queue Length: 2
2016.12.09 10:00:43 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481274043.82694
2016.12.09 10:00:43 5: MiLightBridge1 send: 4e1a55@1481274043.94766; Queue Length: 1
Ich hoffe du kannst damit was anfangen
Gruß
Hallo Daniel,
ja, perfekt. Also Netzwerkprotokoll können wir uns sparen, es kommt genau das an was gesendet wird, ich habs mal chronologisch zusammenkopiert:
Backlight_LCD (RGB) wurden 100% Blau angeschaltet
2016.12.09 09:58:03 4: Backlight_LCD_RGBW_On: Set ON; Ramp: 0
2016.12.09 09:58:03 4: Backlight_LCD_RGBW_Dim: Brightness: 100; Ramp: 0; Flags:
2016.12.09 09:58:03 4: Backlight_LCD_CmdQueue_Clear
2016.12.09 09:58:03 5: Backlight_LCD_HSV_Transition: Prepare Start (actual): 241,100,0@1481273883.3733
2016.12.09 09:58:03 5: MilightDevice_HSVToStr: h:241,s:100,v:0
2016.12.09 09:58:03 4: Backlight_LCD_HSV_Transition: Current: 241,100,0
2016.12.09 09:58:03 4: Backlight_LCD_HSV_Transition: Set: 241,100,100; Ramp: 0; Flags:
2016.12.09 09:58:03 4: Backlight_LCD_HSV_Transition: Set: 241,100,100; No Ramp
2016.12.09 09:58:03 4: Backlight_LCD_CmdQueue_Add: h: 241; s: 100; v: 100; Ctrl ; TargetTime: ; QLen: 1
2016.12.09 09:58:03 5: MilightDevice_RGBW_SetHSV: h:241 s:100 v:100 / cv:16 wl:0 cl:26
2016.12.09 09:58:03 5: MilightDevice_HSVToStr: h:241,s:100,v:100
2016.12.09 09:58:03 4: MiLightBridge1_Write: Command: 4b0055
2016.12.09 09:58:03 5: MiLightBridge1 send: 4b0055@1481273883.4554; Queue Length: 1
Contents: 4B 0 55
Write : B0 63 D2 AF 24 9 79
................
2016.12.09 09:58:03 4: MiLightBridge1_Write: Command: 401055
2016.12.09 09:58:03 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273883.45598. Now: 1481273883.45672
Contents: 40 10 55
Write : B0 63 D2 AF 4 F 7A
................
2016.12.09 09:58:03 4: MiLightBridge1_Write: Command: 4e1a55
2016.12.09 09:58:03 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273883.45598. Now: 1481273883.46058
2016.12.09 09:58:03 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273883.55972
Contents: 4E 1A 55
Write : B0 63 D2 AF C4 E 7B
................
2016.12.09 09:58:03 4: MiLightBridge1_Write: Command: 4b0055
2016.12.09 09:58:03 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273883.45598. Now: 1481273883.46418
2016.12.09 09:58:03 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273883.56361
Contents: 4B 0 55
Write : B0 63 D2 AF C4 9 7C
................
2016.12.09 09:58:03 4: MiLightBridge1_Write: Command: 401055
2016.12.09 09:58:03 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273883.45598. Now: 1481273883.46761
2016.12.09 09:58:03 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273883.56701
Contents: 40 10 55
Write : B0 63 D2 AF 4 F 7D
................
2016.12.09 09:58:03 4: MiLightBridge1_Write: Command: 4e1a55
2016.12.09 09:58:03 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273883.45598. Now: 1481273883.47137
2016.12.09 09:58:03 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273883.57075
2016.12.09 09:58:03 5: Backlight_LCD_CmdQueue_Exec: Next Exec: 1481273883.47451
Contents: 4E 1A 55
Write : B0 63 D2 AF C4 E 7E
................
2016.12.09 09:58:03 5: MiLightBridge1 send: 401055@1481273883.58315; Queue Length: 5
2016.12.09 09:58:03 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273883.57435
2016.12.09 09:58:03 5: MiLightBridge1 send: 4e1a55@1481273883.69602; Queue Length: 4
2016.12.09 09:58:03 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273883.68723
2016.12.09 09:58:03 5: MiLightBridge1 send: 4b0055@1481273883.80865; Queue Length: 3
2016.12.09 09:58:03 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273883.80029
2016.12.09 09:58:03 5: MiLightBridge1 send: 401055@1481273883.92136; Queue Length: 2
2016.12.09 09:58:03 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273883.91258
2016.12.09 09:58:04 5: MiLightBridge1 send: 4e1a55@1481273884.0341; Queue Length: 1
--------------------------------------------
FlurRGBWW (RGBW) wurden 100% Weiß Angeschaltet
2016.12.09 09:59:24 4: FlurRGBWW_RGBW_On: Set ON; Ramp: 0
2016.12.09 09:59:24 4: FlurRGBWW_RGBW_Dim: Brightness: 100; Ramp: 0; Flags:
2016.12.09 09:59:24 4: FlurRGBWW_CmdQueue_Clear
2016.12.09 09:59:24 5: FlurRGBWW_HSV_Transition: Prepare Start (actual): 0,0,0@1481273964.34163
2016.12.09 09:59:24 5: MilightDevice_HSVToStr: h:0,s:0,v:0
2016.12.09 09:59:24 4: FlurRGBWW_HSV_Transition: Current: 0,0,0
2016.12.09 09:59:24 4: FlurRGBWW_HSV_Transition: Set: 0,0,100; Ramp: 0; Flags:
2016.12.09 09:59:24 4: FlurRGBWW_HSV_Transition: Set: 0,0,100; No Ramp
2016.12.09 09:59:24 4: FlurRGBWW_CmdQueue_Add: h: 0; s: 0; v: 100; Ctrl ; TargetTime: ; QLen: 1
2016.12.09 09:59:24 5: MilightDevice_RGBW_SetHSV: h:0 s:0 v:100 / cv:176 wl:26 cl:0
2016.12.09 09:59:24 5: MilightDevice_HSVToStr: h:0,s:0,v:100
2016.12.09 09:59:24 4: MiLightBridge1_Write: Command: 470055
2016.12.09 09:59:24 5: MiLightBridge1 send: 470055@1481273964.42245; Queue Length: 1
Contents: 47 0 55
Write : B0 63 D2 AF C4 5 7F
................
2016.12.09 09:59:24 4: MiLightBridge1_Write: Command: c70055
2016.12.09 09:59:24 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273964.42322. Now: 1481273964.42385
Contents: C7 0 55
Write : B0 63 D2 AF C4 15 80
................
2016.12.09 09:59:24 4: MiLightBridge1_Write: Command: 4e1a55
2016.12.09 09:59:24 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273964.42322. Now: 1481273964.42764
2016.12.09 09:59:24 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273964.52688
Contents: 4E 1A 55
Write : B0 63 D2 AF C2 E 81
................
2016.12.09 09:59:24 4: MiLightBridge1_Write: Command: 470055
2016.12.09 09:59:24 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273964.42322. Now: 1481273964.43173
2016.12.09 09:59:24 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273964.53101
Contents: 47 0 55
Write : B0 63 D2 AF C2 5 82
................
2016.12.09 09:59:24 4: MiLightBridge1_Write: Command: c70055
2016.12.09 09:59:24 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273964.42322. Now: 1481273964.43526
2016.12.09 09:59:24 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273964.5347
Contents: C7 0 55
Write : B0 63 D2 AF C2 15 83
................
2016.12.09 09:59:24 4: MiLightBridge1_Write: Command: 4e1a55
2016.12.09 09:59:24 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481273964.42322. Now: 1481273964.43897
Contents: 4E 1A 55
Write : B0 63 D2 AF C2 E 84
................
2016.12.09 09:59:24 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273964.53833
2016.12.09 09:59:24 5: FlurRGBWW_CmdQueue_Exec: Next Exec: 1481273964.44225
2016.12.09 09:59:24 5: MiLightBridge1 send: c70055@1481273964.55103; Queue Length: 5
2016.12.09 09:59:24 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273964.54204
2016.12.09 09:59:24 5: MiLightBridge1 send: 4e1a55@1481273964.66342; Queue Length: 4
2016.12.09 09:59:24 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273964.65511
2016.12.09 09:59:24 5: MiLightBridge1 send: 470055@1481273964.77567; Queue Length: 3
2016.12.09 09:59:24 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273964.7673
2016.12.09 09:59:24 5: MiLightBridge1 send: c70055@1481273964.88782; Queue Length: 2
2016.12.09 09:59:24 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481273964.87956
2016.12.09 09:59:25 5: MiLightBridge1 send: 4e1a55@1481273965.00582; Queue Length: 1
----------------------------------------------
Flur2_RGBWW (RGBW) wurden 100% Weiß Angeschaltet
2016.12.09 10:00:43 4: Flur2_RGBWW_RGBW_On: Set ON; Ramp: 0
2016.12.09 10:00:43 4: Flur2_RGBWW_RGBW_Dim: Brightness: 100; Ramp: 0; Flags:
2016.12.09 10:00:43 4: Flur2_RGBWW_CmdQueue_Clear
2016.12.09 10:00:43 5: Flur2_RGBWW_HSV_Transition: Prepare Start (actual): 0,0,0@1481274043.29254
2016.12.09 10:00:43 5: MilightDevice_HSVToStr: h:0,s:0,v:0
2016.12.09 10:00:43 4: Flur2_RGBWW_HSV_Transition: Current: 0,0,0
2016.12.09 10:00:43 4: Flur2_RGBWW_HSV_Transition: Set: 0,0,100; Ramp: 0; Flags:
2016.12.09 10:00:43 4: Flur2_RGBWW_HSV_Transition: Set: 0,0,100; No Ramp
2016.12.09 10:00:43 4: Flur2_RGBWW_CmdQueue_Add: h: 0; s: 0; v: 100; Ctrl ; TargetTime: ; QLen: 1
2016.12.09 10:00:43 5: MilightDevice_RGBW_SetHSV: h:0 s:0 v:100 / cv:176 wl:26 cl:0
2016.12.09 10:00:43 5: MilightDevice_HSVToStr: h:0,s:0,v:100
2016.12.09 10:00:43 4: MiLightBridge1_Write: Command: 450055
2016.12.09 10:00:43 5: MiLightBridge1 send: 450055@1481274043.37137; Queue Length: 1
Contents: 45 0 55
Write : B0 63 D2 AF C2 3 85
................
2016.12.09 10:00:43 4: MiLightBridge1_Write: Command: c50055
2016.12.09 10:00:43 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481274043.37215. Now: 1481274043.37272
Contents: C5 0 55
Write : B0 63 D2 AF C2 13 86
................
2016.12.09 10:00:43 4: MiLightBridge1_Write: Command: 4e1a55
2016.12.09 10:00:43 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481274043.37215. Now: 1481274043.37629
2016.12.09 10:00:43 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481274043.47551
Contents: 4E 1A 55
Write : B0 63 D2 AF C1 E 87
................
2016.12.09 10:00:43 4: MiLightBridge1_Write: Command: 450055
2016.12.09 10:00:43 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481274043.37215. Now: 1481274043.3801
2016.12.09 10:00:43 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481274043.47924
Contents: 45 0 55
Write : B0 63 D2 AF C1 3 88
................
2016.12.09 10:00:43 4: MiLightBridge1_Write: Command: c50055
2016.12.09 10:00:43 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481274043.37215. Now: 1481274043.3837
2016.12.09 10:00:43 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481274043.4831
Contents: C5 0 55
Write : B0 63 D2 AF C1 13 89
................
2016.12.09 10:00:43 4: MiLightBridge1_Write: Command: 4e1a55
2016.12.09 10:00:43 5: MiLightBridge1_cmdQueue_Send: Waiting for send interval. cmdLastSent: 1481274043.37215. Now: 1481274043.38702
2016.12.09 10:00:43 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481274043.48648
Contents: 4E 1A 55
Write : B0 63 D2 AF C1 E 8A
2016.12.09 10:00:43 5: Flur2_RGBWW_CmdQueue_Exec: Next Exec: 1481274043.39018
2016.12.09 10:00:43 5: MiLightBridge1 send: c50055@1481274043.4985; Queue Length: 5
2016.12.09 10:00:43 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481274043.49004
2016.12.09 10:00:43 5: MiLightBridge1 send: 4e1a55@1481274043.61091; Queue Length: 4
2016.12.09 10:00:43 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481274043.60274
2016.12.09 10:00:43 5: MiLightBridge1 send: 450055@1481274043.72306; Queue Length: 3
2016.12.09 10:00:43 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481274043.71466
2016.12.09 10:00:43 5: MiLightBridge1 send: c50055@1481274043.83494; Queue Length: 2
2016.12.09 10:00:43 5: MiLightBridge1_CmdQueue_Send: Remove timer at: 1481274043.82694
2016.12.09 10:00:43 5: MiLightBridge1 send: 4e1a55@1481274043.94766; Queue Length: 1
................
Das NRF Protokoll ist folgendermaßen aufgebaut:
B0 F2 EA 6D B0 02 f0
| | | | |
| | | | sequence number
| | | Button_of_Remote
| | brightness
| color
ID_of_Remote (3 byte) - change to your ID
Wenn man das NRF Protokoll analysiert dann sieht man dass folgendes passiert:
Backlight_LCD (RGB) wurden 100% Blau angeschaltet
Contents: 4B 0 55
Write : B0 63 D2 AF 24 9 79 --> Taste 9 --> Gruppe 4 einschalten
................
Contents: 40 10 55
Write : B0 63 D2 AF 4 F 7A --> Taste 0x0F (Farbrad) auf Blau
................
Contents: 4E 1A 55
Write : B0 63 D2 AF C4 E 7B --> Taste 0x0E (Helligkeit) auf C4
bei den RBGW Bulbs passiert folgendes:
FlurRGBWW (RGBW) wurden 100% Weiß Angeschaltet
Contents: 47 0 55
Write : B0 63 D2 AF C4 5 7F --> Taste 5 --> Gruppe 2 einschalten
................
Contents: C7 0 55
Write : B0 63 D2 AF C4 15 80 --> group2white="\xC7\00\x55" --> Gruppe 2 auf weiss
................
Contents: 4E 1A 55
Write : B0 63 D2 AF C2 E 81 --> Taste 0x0E (Helligkeit) auf C2
Das bedeutet für mich dass die Bridge genau das tut was von FHEM kommt, und das müsste dann mit Original Bridge genauso aussehen.
Aber vielleich solltest du mal die pairings löschen, und neu pairen, vielleicht hast du die RBG Bulb auf Gruppe 2 und Gruppe 4 gepaired?
Gruß
Karl
Danke für die tolle erklärung. Jetzt bin ich wieder etwas Schlauer. :)
Kannst du mir erklären wie ich die pairings löschen kann?
Zitat von: Daniel_D am 09 Dezember 2016, 13:42:02
Danke für die tolle erklärung. Jetzt bin ich wieder etwas Schlauer. :)
Kannst du mir erklären wie ich die pairings löschen kann?
Das ist immer ein Krampf, ich bringe das nur mit einer Fernbedienung zusammen, hier die Beschreibung aus dem Manual
3.3.5 Clear/ResettheLimitlessLEDBulbOccasionally you may wish to swap the LED bulb from one channel to another on the same remote, or the Bulb has stopped responding to a remote. The best way to do this, is to clear/reset the bulb, that way all remotes will no longer be synchronized to this bulb. This will then allow you tore-synchronize each remote to the bulb again, and allows you to select a new channel on each remote or wifi bridge (via app).• Switch off the power to the socket of the bulb/s that you are going to clear/reset.• Switch the wall switch back on, and within 2 seconds, quickly press 5 times (or long press and hold), the "All On" button or "Channel On" button• The LED bulb will blink 6 times to confirm that it has now cleared/reset.
Danach sind dann alle Pairings gelöscht.
Sent from my iPad using Tapatalk
Danke!
Dann muss ich mir wohl erstmal eine Fernbedienung besorgen!
Zitat von: Daniel_D am 09 Dezember 2016, 15:33:22
Danke!
Dann muss ich mir wohl erstmal eine Fernbedienung besorgen!
Es müsste auch mit der app und der original bridge funktionieren, vielleicht gehts ja bei dir auch über FHEM, geht ja nur darum nach dem Spannung anlegen die Kommandos rechtzeitig abzusetzen, versuch es einfach.
Sent from my iPad using Tapatalk
Hat auch nach langem auch mit der App funktioniert. Wenn man weiß wie es geht ganz Easy.
Hab erst alles unpairt dann wieder alles mit FHEM gepairt. Und jetzt läuft es vernüftig.
Danke Euch
Edit:
Geht leider doch nicht. Immer noch das selbe Problem. Muss an der Bridge mit dem RGB Bulb liegen. Weil mit der Originalen Bridge läuft es.
Habe mehrere Probiert, leider ohne Erfolg :(
Habe jetzt mal 2 aufgebaut mit 2 ESP aber empfangen und senden ist nicht :(
Keine Ahnung wo der Fehler liegen könnte.
Arduino IDE 1.6.13
RF24 ist die 1.2.0
* VCC 3,3v
* CE D2
* CSN/CS D8
* SCK D5
* MISO D6
* MOSI D7
* GND GND
Zitat von: Daniel_D am 09 Dezember 2016, 17:18:54
Hat auch nach langem auch mit der App funktioniert. Wenn man weiß wie es geht ganz Easy.
Hab erst alles unpairt dann wieder alles mit FHEM gepairt. Und jetzt läuft es vernüftig.
Danke Euch
Edit:
Geht leider doch nicht. Immer noch das selbe Problem. Muss an der Bridge mit dem RGB Bulb liegen. Weil mit der Originalen Bridge läuft es.
probier mal die milightbridge auf port 8898 oder 8897 umzustellen, danach musst du du die Lampen nochmal pairen. In der Konsole müsstest du dann eine andere fb adresse bekommen.
Sent from my iPad using Tapatalk
Zitatprobier mal die milightbridge auf port 8898 oder 8897 umzustellen, danach musst du du die Lampen nochmal pairen.
Ich habe die mit der ESPBridge über FHEM gepairt. Sollte ich die mit MiLight Bridge pairen?
Dann kann ich die aber nicht in Fhem ohne die MiLight Bridge steuern. Oder sehe ich das Falsch?
Zitat von: Maiks am 09 Dezember 2016, 18:41:59
Habe mehrere Probiert, leider ohne Erfolg :(
Habe jetzt mal 2 aufgebaut mit 2 ESP aber empfangen und senden ist nicht :(
Keine Ahnung wo der Fehler liegen könnte.
Arduino IDE 1.6.13
RF24 ist die 1.2.0
* VCC 3,3v
* CE D2
* CSN/CS D8
* SCK D5
* MISO D6
* MOSI D7
* GND GND
Ich habe Arduino 1.6.12 , esp 2.3.0 und nrf24 v1.1.7 von TMRh20 eingesetzt .
Die Verkabelung stimmt ja, genauso wie auch im Sketch beschrieben. Welches ESP board und welches NRF24 Modul nutzt du?
Sent from my iPad using Tapatalk
Zitat von: Daniel_D am 09 Dezember 2016, 19:35:09
Ich habe die mit der ESPBridge über FHEM gepairt. Sollte ich die mit MiLight Bridge pairen?
Dann kann ich die aber nicht in Fhem ohne die MiLight Bridge steuern. Oder sehe ich das Falsch?
Ich glaube jetzt reden wir aneinander vorbei. Du hast die Lampe in FHEM angelegt. Diese verwenden ein IODevice, ich meine mich zu erinnern milightbridge1 oder so ähnlich. Die originale bridge (die Hardware) verwendet den port 8899, die esp bridge unterstützt auch die ports 8896-8899, d.h. wenn du deine milightbridge definition von port 8899 auf 8898 veränderst dann musst du die Lampe aus FHEM neu pairen, das port wird nämlich für die generierung der Fernbedienungsadresse verwendet. Das ist also wie eine neue FB anlernen. Jede Lampe kann an bis zu 4 FB/Controller angelernt und bedient werden.
Aus den Logs die gesendet hast geht hervor dass die RGB Lampe offensichtlich auf Befehle der Gruppe 2 und Gruppe 4 der Fernbedienung B0 63 D2 reagiert (esp bridge).
Zitat von: schka17 am 09 Dezember 2016, 19:56:23
Ich habe Arduino 1.6.12 , esp 2.3.0 und nrf24 v1.1.7 von TMRh20 eingesetzt .
Die Verkabelung stimmt ja, genauso wie auch im Sketch beschrieben. Welches ESP board und welches NRF24 Modul nutzt du?
Sent from my iPad using Tapatalk
NodeMCU und NRF24L01+ Ich habe jetzt mal aus dem Beispiel ein vom RF24 das getting Startet genommen, dort habe ich eine kommunikation zwischen den beiden ESP oder 2 nano. Das funktioniert Funktioniert.
Nach dem ich 2 ESP geflasht habe und in FHEM eingerichtet, sehe ich über die Serielle Konsole des Sendenden die befehle, aber auf der Seriellen Konsole des anderen sehe ich nichts, sollte dort das Empfangene nicht auch zu sehen sein ( Habe das GW und openmili5 ausprobiert)
ZitatNach dem ich 2 ESP geflasht habe und in FHEM eingerichtet, sehe ich über die Serielle Konsole des Sendenden die befehle, aber auf der Seriellen Konsole des anderen sehe ich nichts, sollte dort das Empfangene nicht auch zu sehen sein ( Habe das GW und openmili5 ausprobiert)
ja, genau.
Habe jetzt mal einen Sniffer für den NANO geflasht, der empfängt jetzt die Signale vom ESP :D
Allerdings nicht von meiner Fernbedienung, es scheint so als wenn meine Lampen doch das neuere MILIGHT verwenden mit einer anderen ID, muss jezt mals schauen wie ich das anpassen kann :(
Zitat von: Maiks am 09 Dezember 2016, 20:43:12
Habe jetzt mal einen Sniffer für den NANO geflasht, der empfängt jetzt die Signale vom ESP :D
Allerdings nicht von meiner Fernbedienung, es scheint so als wenn meine Lampen doch das neuere MILIGHT verwenden mit einer anderen ID, muss jezt mals schauen wie ich das anpassen kann :(
Ok, damit habe ich mich auch noch nicht auseinandergesetzt, welche Version hast du da?
Sent from my iPad using Tapatalk
Wie kann ich den Port denn wechseln? Der wird doch automatisch vergeben.
Steh ein wenig auf dem schlauch.
Zitat von: Daniel_D am 10 Dezember 2016, 00:54:51
Wie kann ich den Port denn wechseln? Der wird doch automatisch vergeben.
Steh ein wenig auf dem schlauch.
Nun, du öffnest die Detailansicht deiner MilightBridge1, drückst auf den Def Button, im Fenster der Devicedefinition gibst du nach der IP Adresse
:8898
ein.
Speichern, fertig
Sent from my iPad using Tapatalk
Danke,
das ist ja Easy.
Teste ich nachher mal!
EDIT: Hat auch keine Änderung gebracht :-\
Also dann weiss ich jetzt auch nicht mehr weiter, das einzige was man noch schauen könnte wäre was denn die originale Bridge im HF Bereich sendet, du könntest den openmili sketch flashen und dann mal genau die Sequenz aus dem Log durchspielen und aufzeichnen.
Sent from my iPad using Tapatalk
Das mach ich die Tage vielleicht mal.
Danke und noch ein schönes Rest Wochenende
Yeah!
Ich habs geschafft eine Birne zu pairen. Allerdings ganz klassisch als Milight-Bridge über fhem. Wie geht das ganze über mqtt?
Also wie bekomme ich die Fernbedienungskommandos zur Birne mit rein?
Zitat von: Bapt. Reverend Magersuppe am 11 Dezember 2016, 15:46:25
Yeah!
Ich habs geschafft eine Birne zu pairen. Allerdings ganz klassisch als Milight-Bridge über fhem. Wie geht das ganze über mqtt?
Also wie bekomme ich die Fernbedienungskommandos zur Birne mit rein?
Das Senden per MQTT ist in meiner Bridge nicht implementiert, es gibt ja auch dafür keine Modulunterstützung, zumindest bis jetzt. MQTT ist nur mal als "machbarkeit" für die Rückmeldung an FHEM implementiert, wenn man über eine Fernbedienung schaltet.
Sent from my iPad using Tapatalk
Hmm.... klingt sehr interessant....
Hab mich hier mal ein wenig eingelesen, verstehe aber noch nicht alles.
Würde den Sketch evtl für Ethernet-Shield anstatt WLAN portieren.
Aber bevor ich mich an die Arbeit mache, hätt ich noch ein paar Fragen:
1) Versteh ich das richtig, daß hier eine Emulation von bis zu vier Milight-Bridges möglich ist?
2) Mit der gleichen Hardware wie für mysensors?
3) Die einzelnen Bridges können dann per wifilight-modul aus fhem her angesteuert werden?
4) WIe ist denn die Reichweite? So wie bei mysensors oder so wie bei milight? Habe auch mysensors im Einsatz und hier ist die Reichweite nicht so berauschend. Die von milight ist besser....
Da ich vier milight-bridges im Einsatz habe und die nicht wirklich stabil sind, wäre das der Wahnsinn.
Cheers,
Pula
Zu 1.) mit dem geposteten sketch ja, kann man aber ausbauen
2, ja
3, nein, beim Wifilight kann man nur eine bridge, bzw. Nur ein Port definieren. Allerdings, wenn ich das so schreibe, möglicherweise kann man mehrere Devices mit derselben Ip-Adresse aber unterschiedliche Ports definieren. Habe ich noch nicht ausprobiert, ich verwende das Milight Modul, da funktioniert es.
4., da kann ich nicht viel negatives sagen, ich habe weder mit milight noch mit mysensors ein Reichweitenproblem, meine milights sind aber auch nur im umkreis von ca. 60m2 und geht auch durch die Decke, ich verwende aber auch das +Modul mit der externen Antenne.
Und zum letzten Punkt, ausser beim ausfall des AP's(also die Idee mit Ethernet ist nicht so schlecht) hatte ich seither keine Ausfälle mehr.
Sent from my iPad using Tapatalk
Klingt mal gut :-)
Und zum testen sollte mit der app ein pairing möglich sein?
Cheers,
Pula
Hi,
hab das jetzt mal mit einem rumliegenden UNO und Ethernet-Shield soweit ans laufen gebracht...
Serial-Out zb:
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 81 13 2E
Aber jetzt hänge ich. Hab eine milight-bridge in fhem angelegt:
define milightbridge1 MilightBridge 192.168.1.177:8899
attr milightbridge1 checkInterval 10
attr milightbridge1 event-on-change-reading state
attr milightbridge1 protocol udp
attr milightbridge1 room Beleuchtung
attr milightbridge1 sendInterval 100
und ein entsprechendes device:
define testlampe MilightDevice RGBW milightbridge1 5
attr testlampe IODev milightbridge1
attr testlampe devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
attr testlampe event-on-change-reading state,transitionInProgress
attr testlampe lightSceneParamsToSave hsv
attr testlampe restoreAtStart 1
attr testlampe room Beleuchtung
attr testlampe webCmd on:off:dim:hue:night:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffff00
Aber irgendwie wird das mit dem pairen nichts. Habe der Lampe Strom gegeben und sofort ein set testlampe rgb ffffff geschickt, keine Reaktion der Lampe. Auch diverse andere Schaltversuche aus fhem entlocken der Lampe keine Reaktion.
Für eine kleine Hilfestellung wäre ich dankbar. Ach ja. Obwohl 8899 ja eigentlich der Standard-Port einer V3/V4 Bridge sein soll, sehe ich das Ding nicht in der Android-App. Gehört das so?
Cheers,
Pula
Die app wird nicht unterstützt, also die kommunikation mit der app ist nicht implementiert.
Hast du probiert einfach nach dem Strom geben nur ein set on zu schicken?
Für weitere Diagnose würde ich dann den Output auf dem seriellen Port benötigen.
Sent from my iPad using Tapatalk
Hi,
interessant, ich bekomme etliche Woops, die ich nicht wirklich deuten kann:
Booting openmili2
Ethernet connected
# OpenMiLight Receiver/Transmitter starting
Wooops!
Write : B0 63 D2 0 0 BE 1
Wooops!
Write : B0 63 D2 0 0 BE 2
...Wooops!
Write : B0 63 D2 0 0 BE 3
Wooops!
Write : B0 63 D2 0 0 BE 4
...Wooops!
Write : B0 63 D2 0 0 BE 5
Wooops!
Write : B0 63 D2 0 0 BE 6
...Wooops!
Write : B0 63 D2 0 0 BE 7
Wooops!
Write : B0 63 D2 0 0 BE 8
...Wooops!
Write : B0 63 D2 0 0 BE 9
Wooops!
Write : B0 63 D2 0 0 BE A
....Wooops!
Write : B0 63 D2 0 0 BE B
Wooops!
Write : B0 63 D2 0 0 BE C
................Wooops!
Write : B0 63 D2 0 0 BE D
Wooops!
Der Sketch sieht so aus (kein Hexenwerk gegenüber Deinem - und ich hab noch diverse debut-prints drin....):
#include <SPI.h>
#include "nRF24L01.h"
//#include <RF24.h>
#include <MySensor.h>
#include "PL1167_nRF24.h"
#include "MiLightRadio.h"
//#include <ESP8266_Basic.h>
//#include <ESP8266WiFi.h>
//#include <WiFiUdp.h>
#include <Ethernet.h>
//#include <printf.h>
byte mac[] = {
0xD0, 0xAD, 0xCE, 0xFF, 0xFE, 0xED
};
IPAddress ip(192, 168, 1, 177);
EthernetUDP udp1;
EthernetUDP udp2;
EthernetUDP udp3;
EthernetUDP udp4;
uint8_t udp1Id[] = {0x63, 0xD2};
uint8_t udp2Id[] = {0x63, 0xD3};
uint8_t udp3Id[] = {0x63, 0xD0};
uint8_t udp4Id[] = {0x63, 0xC2};
char packetBuffer[255];
/*
* nRF24L01+ ESP8266 NodeMCU
* VCC VCC VCC
* CE GPIO4 D2
* CSN/CS GPIO15 D8
* SCK GPIO14 D5
* MISO GPIO12 D6
* MOSI GPIO13 D7
* GND GND GND
*/
#define CE_PIN 4 //
#define CSN_PIN 15 //
RF24 radio(CE_PIN, CSN_PIN);
PL1167_nRF24 prf(radio);
MiLightRadio mlr(prf);
//Thanks to Henryk and Erantimus for providing details and checksum code.
//Calculate Checksum - Returns 2 bytes.
uint16_t calc_crc(uint8_t data[], uint8_t data_length = 0x08) {
uint16_t state = 0;
for (uint8_t i = 0; i < data_length; i++) {
uint8_t byte = data[i];
for (int j = 0; j < 8; j++) {
if ((byte ^ state) & 0x01) {
state = (state >> 1) ^ 0x8408;
} else {
state = state >> 1;
}
byte = byte >> 1;
}
}
return state;
}
uint8_t resendCounter = 0;
uint8_t lastOnGroup = 0;
long unsigned int lastMicros = 0;
void setup()
{
Serial.begin(115200);
delay(10);
Serial.println();
Serial.println();
// Serial.print("Connecting to ");
// Serial.println(ssid);
Ethernet.begin(mac, ip);
//Ethernet.begin(mac, ip, myDns, gateway, subnet);
Serial.println("");
Serial.println("Booting openmili2");
Serial.println("Ethernet connected");
//Serial.println("IP address: ");
//Serial.println(WiFi.localIP());
udp1.begin(8899);
udp2.begin(8898);
udp3.begin(8897);
udp4.begin(8896);
/*entfernt schka17 20161006
*
printf_begin(); */
delay(1000);
Serial.println("# OpenMiLight Receiver/Transmitter starting");
mlr.begin();
}
static int dupesPrinted = 0;
static bool receiving = false;
static bool escaped = false;
static uint8_t outgoingPacket[7];
static uint8_t outgoingPacketUDP[7];
static uint8_t outgoingPacketPos = 0;
static uint8_t nibble;
static enum {
IDLE,
HAVE_NIBBLE,
COMPLETE,
} state;
static uint8_t reverse_bits(uint8_t data) {
uint8_t result = 0;
for (int i = 0; i < 8; i++) {
result <<= 1;
result |= data & 1;
data >>= 1;
}
return result;
}
void udpLoop(EthernetUDP Udp, uint8_t id1, uint8_t id2) {
int packetSize = Udp.parsePacket();
//Serial.println("UdpLoop ");
if (packetSize)
{
outgoingPacketUDP[0] = 0xB0; // B0 - White | B8 - RGBW
outgoingPacketUDP[1] = id1; // Remote ID
outgoingPacketUDP[2] = id2; // Remote ID
//Serial.println("UdpLoop 1");
if (packetBuffer[0] == 0x40) { // Color
//Serial.println("UdpLoop 2");
outgoingPacketUDP[3] = ((uint8_t)0xFF - packetBuffer[1]) + 0xC0;
outgoingPacketUDP[4] = lastOnGroup; // Use last ON group
outgoingPacketUDP[5] = 0x0F; // Button
//Serial.println("UdpLoop 3");
} else if (packetBuffer[0] == 0x4E) { // Brightness
//Serial.println("UdpLoop 4");
// 2 to 1B (2-27)
// (0x90-0x00 and 0xF8-0xB0) increments of 8
// 0x90-0x00 = 1 to 18
// 0xB0-F8 = 19 to 27
/*
* x - 98
* x - 90
* x - 88
* 2 - 80*
* 3 - 78
* 4 - 70
* 5 - 68
* 6 - 60
* 7 - 58
* 8 -50
* 9 - 48
* 10 - 40
* 11 - 38
* 12 - 30
* 13 - 28
* 14 - 20
* 15 - 18
* 16 - 10
* 17 - 8
* 18 - 0
* 19 - F8
* 20 - F0
* 21 - E8
* 22 - E0
* 23 - D8
* 24 - D0
* 25 - C8
* 26 - C0
* 27 - B8*
* xx - B0
* xx - A8
*/
if (packetBuffer[1] <= 18) {
outgoingPacketUDP[4] = (18 - packetBuffer[1]) * 0x08;
} else {
outgoingPacketUDP[4] = 0xB8 + (27 - packetBuffer[1]) * 0x08;
}
outgoingPacketUDP[4] += lastOnGroup; // add group number
outgoingPacketUDP[5] = 0x0E; // Button
} else if ((packetBuffer[0] & 0xF0) == 0xC0) {
outgoingPacketUDP[5] = packetBuffer[0] - 0xB2; // Full White
} else if (packetBuffer[0] == 0x41) { // Button RGBW COLOR LED ALL OFF
outgoingPacketUDP[5] = 0x02;
} else if (packetBuffer[0] == 0x42) { // Button RGBW COLOR LED ALL ON
outgoingPacketUDP[5] = 0x01;
lastOnGroup = 0;
} else if (packetBuffer[0] == 0x45) { // Group 1 ON
outgoingPacketUDP[5] = 0x03;
lastOnGroup = 1;
} else if (packetBuffer[0] == 0x46) { // Group 1 OFF
outgoingPacketUDP[5] = 0x04;
} else if (packetBuffer[0] == 0x47) { // Group 2 ON
outgoingPacketUDP[5] = 0x05;
lastOnGroup = 2;
} else if (packetBuffer[0] == 0x48) { // Group 2 OFF
outgoingPacketUDP[5] = 0x06;
} else if (packetBuffer[0] == 0x49) { // Group 3 ON
outgoingPacketUDP[5] = 0x07;
lastOnGroup = 3;
} else if (packetBuffer[0] == 0x4A) { // Group 3 OFF
outgoingPacketUDP[5] = 0x08;
} else if (packetBuffer[0] == 0x4B) { // Group 4 ON
outgoingPacketUDP[5] = 0x09;
lastOnGroup = 4;
} else if (packetBuffer[0] == 0x4C) { // Group 5 OFF
outgoingPacketUDP[5] = 0x0A;
} else {
Serial.println("Wooops!");
outgoingPacketUDP[5] = packetBuffer[0] - 0x42; // Button
}
//Serial.println("UdpLoop 5");
outgoingPacketUDP[6]++; // Counter
//Serial.println("UdpLoop 6");
Serial.print("Write : ");
for (int j = 0; j < sizeof(outgoingPacketUDP); j++) {
Serial.print(outgoingPacketUDP[j], HEX);
Serial.print(" ");
}
Serial.println();
//Serial.println("UdpLoop 7");
mlr.write(outgoingPacketUDP, sizeof(outgoingPacketUDP));
resendCounter = 16;
lastMicros = micros();
//Serial.println("UdpLoop 8");
}
delay(0);
if (resendCounter > 0) {
if (micros() - 350 > lastMicros) {
mlr.resend();
resendCounter--;
Serial.print(".");
lastMicros = micros();
}
}
//Serial.println("UdpLoop end");
}
void loop()
{
udpLoop(udp1, udp1Id[0], udp1Id[1]);
udpLoop(udp2, udp2Id[0], udp2Id[1]);
udpLoop(udp3, udp3Id[0], udp3Id[1]);
udpLoop(udp4, udp4Id[0], udp4Id[1]);
if (receiving) {
if (mlr.available()) {
printf("\n");
//Serial.println();
uint8_t packet[7];
size_t packet_length = sizeof(packet);
mlr.read(packet, packet_length);
for (int i = 0; i < packet_length; i++) {
Serial.print(packet[i], HEX);
Serial.print(" ");
printf("%02X ", packet[i]);
}
}
int dupesReceived = mlr.dupesReceived();
for (; dupesPrinted < dupesReceived; dupesPrinted++) {
printf(".");
Serial.print(".");
}
}
while (Serial.available()) {
yield();
char inChar = (char)Serial.read();
uint8_t val = 0;
bool have_val = true;
if (inChar >= '0' && inChar <= '9') {
val = inChar - '0';
} else if (inChar >= 'a' && inChar <= 'f') {
val = inChar - 'a' + 10;
} else if (inChar >= 'A' && inChar <= 'F') {
val = inChar - 'A' + 10;
} else {
have_val = false;
}
if (!escaped) {
if (have_val) {
switch (state) {
case IDLE:
nibble = val;
state = HAVE_NIBBLE;
break;
case HAVE_NIBBLE:
if (outgoingPacketPos < sizeof(outgoingPacket)) {
outgoingPacket[outgoingPacketPos++] = (nibble << 4) | (val);
} else {
Serial.println("# Error: outgoing packet buffer full/packet too long");
}
if (outgoingPacketPos >= sizeof(outgoingPacket)) {
state = COMPLETE;
} else {
state = IDLE;
}
break;
case COMPLETE:
Serial.println("# Error: outgoing packet complete. Press enter to send.");
break;
}
} else {
switch (inChar) {
case ' ':
case '\n':
case '\r':
case '.':
if (state == COMPLETE) {
Serial.print("Write : ");
for (int j = 0; j < sizeof(outgoingPacket); j++) {
Serial.print(outgoingPacket[j], HEX);
Serial.print(" ");
}
Serial.print(" - Size : ");
Serial.print(sizeof(outgoingPacket), DEC);
Serial.println();
mlr.write(outgoingPacket, sizeof(outgoingPacket));
Serial.println("Write End");
}
if (inChar != ' ') {
outgoingPacketPos = 0;
state = IDLE;
}
if (inChar == '.') {
mlr.resend();
delay(1);
}
break;
case 'x':
Serial.println("# Escaped to extended commands: r - Toggle receiver; Press enter to return to normal mode.");
escaped = true;
break;
}
}
} else {
switch (inChar) {
case '\n':
case '\r':
outgoingPacketPos = 0;
state = IDLE;
escaped = false;
break;
case 'r':
receiving = !receiving;
if (receiving) {
Serial.println("# Now receiving");
} else {
Serial.println("# Now not receiving");
}
break;
}
}
}
}
Ich fürchte den sketch zu analysieren übersteigt meine Kenntnisse und Möglichkeiten (testequipment), aber es sieht für mich so aus als würden die empfangenen Pakete nicht richtig ausgelesen werden, vielleicht ist die Datenstruktur der ethernet library unterschiedlich? Lass dir mal den inhalt von packetbuffer auf die serial ausgeben
Sent from my iPad using Tapatalk
Ok, ich werde mir das mal über die feiertage anschauen...
melde mich, falls ich den sketch dann fertig habe....
Cheers und schöne Weihnachten!
Pula
Arghh... ich honk hatte versehentlich den Teil im Sketch gelöscht, in dem der Packetbuffer eingelesen wird...
Keine errors mehr im serial-out, aber gehen tut es trotzdem noch nicht... mal schauen, vielleicht werde ich über die Feiertage schlauer....
Hmm...
vom code und der serial-ausgabe her sieht eigentlich alles gut aus. aber ich bekomm kein pairing mit dem ethernet-sketch...
ich hab mal folgendes in fhem angelegt:
Internals:
CFGFN
CHANGED
Clients :MilightDevice:
DEF 192.168.1.177:8899
HOST 192.168.1.177
INTERVAL 100
NAME milightbridge1
NR 105823
NTFY_ORDER 50-milightbridge1
PORT 8899
SENDFAIL 0
STATE ok
TYPE MilightBridge
cmdLastSent 1482783739.07269
cmdQueueLock 0
0:
1:
2:
3:
4:
5:
NAME testlampe
6:
7:
8:
Matchlist:
1:MilightDevice .*
Readings:
2016-12-26 21:23:54 sendFail 0
2016-12-26 21:21:20 slot0
2016-12-26 21:21:20 slot1
2016-12-26 21:21:20 slot2
2016-12-26 21:21:20 slot3
2016-12-26 21:21:20 slot4
2016-12-26 21:21:20 slot5 testlampe
2016-12-26 21:21:20 slot6
2016-12-26 21:21:20 slot7
2016-12-26 21:21:20 slot8
2016-12-26 21:23:54 state ok
cmdQueue:
Helper:
Attributes:
checkInterval 10
event-on-change-reading state
protocol udp
room Beleuchtung
sendInterval 100
und die lampe:
Internals:
CFGFN
DEF RGBW milightbridge1 5
INIT 1
IODev milightbridge1
LEDTYPE RGBW
NAME testlampe
NR 105825
NTFY_ORDER 50-testlampe
SLOT 5
SLOTID 5
STATE on 36
TYPE MilightDevice
Readings:
2016-12-26 21:22:18 brightness 36
2016-12-26 21:22:16 brightness_on 36
2016-12-26 21:22:18 discoMode 0
2016-12-26 21:22:18 discoSpeed 0
2016-12-26 21:22:18 hsv 0,0,36
2016-12-26 21:22:18 hue 0
2016-12-26 21:22:18 previousState 0,0,0
2016-12-26 21:22:18 rgb 5B5B5B
2016-12-26 21:22:18 saturation 0
2016-12-26 21:22:18 state on 36
2016-12-26 21:22:18 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 1482783738.56069
targetVal 36
whiteLevel 10
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 milightbridge1
devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
event-on-change-reading state,transitionInProgress
lightSceneParamsToSave hsv
restoreAtStart 1
room Beleuchtung
webCmd on:off:dim:hue:night:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffff00
wenn ich ein paar mal bei der lampe on und off hintereinander mache, bekomme ich in der serial-out:
Booting openmili2
Ethernet connected
# OpenMiLight Receiver/Transmitter starting
Contents: 45 0 55
Write : B0 63 D2 0 0 3 1
.....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 0 13 2
....
Contents: 4E A 55
Write : B0 63 D2 0 41 E 3
....
Contents: 45 0 55
Write : B0 63 D2 0 41 3 4
....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 41 13 5
....
Contents: 4E A 55
Write : B0 63 D2 0 41 E 6
................
Contents: 45 0 55
Write : B0 63 D2 0 41 3 7
.....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 41 13 8
....
Contents: 4E 2 55
Write : B0 63 D2 0 81 E 9
....
Contents: 45 0 55
Write : B0 63 D2 0 81 3 A
....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 81 13 B
....
Contents: 4E 2 55
Write : B0 63 D2 0 81 E C
....
Contents: 46 0 55
Write : B0 63 D2 0 81 4 D
....
Contents: 46 0 55
Write : B0 63 D2 0 81 4 E
................
Contents: 45 0 55
Write : B0 63 D2 0 81 3 F
.....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 81 13 10
....
Contents: 4E A 55
Write : B0 63 D2 0 41 E 11
....
Contents: 45 0 55
Write : B0 63 D2 0 41 3 12
....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 41 13 13
....
Contents: 4E A 55
Write : B0 63 D2 0 41 E 14
................
Contents: 45 0 55
Write : B0 63 D2 0 41 3 15
.....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 41 13 16
....
Contents: 4E 2 55
Write : B0 63 D2 0 81 E 17
....
Contents: 45 0 55
Write : B0 63 D2 0 81 3 18
....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 81 13 19
....
Contents: 4E 2 55
Write : B0 63 D2 0 81 E 1A
....
Contents: 46 0 55
Write : B0 63 D2 0 81 4 1B
....
Contents: 46 0 55
Write : B0 63 D2 0 81 4 1C
................
Contents: 45 0 55
Write : B0 63 D2 0 81 3 1D
.....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 81 13 1E
....
Contents: 4E A 55
Write : B0 63 D2 0 41 E 1F
....
Contents: 45 0 55
Write : B0 63 D2 0 41 3 20
....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 41 13 21
....
Contents: 4E A 55
Write : B0 63 D2 0 41 E 22
................
Contents: 45 0 55
Write : B0 63 D2 0 41 3 23
.....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 41 13 24
....
Contents: 4E 2 55
Write : B0 63 D2 0 81 E 25
....
Contents: 45 0 55
Write : B0 63 D2 0 81 3 26
....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 81 13 27
................
Contents: 4E 2 55
Write : B0 63 D2 0 81 E 28
.....
Contents: 46 0 55
Write : B0 63 D2 0 81 4 29
....
Contents: 46 0 55
Write : B0 63 D2 0 81 4 2A
....
Contents: 45 0 55
Write : B0 63 D2 0 81 3 2B
....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 81 13 2C
................
Contents: 4E A 55
Write : B0 63 D2 0 41 E 2D
.....
Contents: 45 0 55
Write : B0 63 D2 0 41 3 2E
....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 41 13 2F
....
Contents: 4E A 55
Write : B0 63 D2 0 41 E 30
....
Contents: 45 0 55
Write : B0 63 D2 0 41 3 31
.............
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 41 13 32
....
Contents: 4E 2 55
Write : B0 63 D2 0 81 E 33
....
Contents: 45 0 55
Write : B0 63 D2 0 81 3 34
....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 81 13 35
....
Contents: 4E 2 55
Write : B0 63 D2 0 81 E 36
......
Contents: 46 0 55
Write : B0 63 D2 0 81 4 37
....
Contents: 46 0 55
Write : B0 63 D2 0 81 4 38
....
Contents: 45 0 55
Write : B0 63 D2 0 81 3 39
....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 81 13 3A
....
Contents: 4E A 55
Write : B0 63 D2 0 41 E 3B
....
Contents: 45 0 55
Write : B0 63 D2 0 41 3 3C
....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 41 13 3D
....
Contents: 4E A 55
Write : B0 63 D2 0 41 E 3E
................
Contents: 45 0 55
Write : B0 63 D2 0 41 3 3F
.....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 41 13 40
....
Contents: 4E 2 55
Write : B0 63 D2 0 81 E 41
....
Contents: 45 0 55
Write : B0 63 D2 0 81 3 42
....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 81 13 43
....
Contents: 4E 2 55
Write : B0 63 D2 0 81 E 44
....
Contents: 46 0 55
Write : B0 63 D2 0 81 4 45
....
Contents: 46 0 55
Write : B0 63 D2 0 81 4 46
................
Contents: 45 0 55
Write : B0 63 D2 0 81 3 47
.....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 81 13 48
....
Contents: 4E A 55
Write : B0 63 D2 0 41 E 49
....
Contents: 45 0 55
Write : B0 63 D2 0 41 3 4A
....
Contents: FFFFFFC5 0 55
Write : B0 63 D2 0 41 13 4B
....
Contents: 4E A 55
Write : B0 63 D2 0 41 E 4C
................
Kann mir mal jemand einen serial-out einer funktionierenden Installation schicken bitte? Vielleicht ist da im Ethernet-Sketch noch ein bug? Hab leider keinen esp zum vergleichen....
Cheers,
Pula
Ich habe jetzt auch gerade nicht die Möglichkeit, aber in Beitrag #57 sind ein paar zum Vergleich.
Sent from my iPad using Tapatalk
Hi,
hab jetzt ein paar Sachen umgestellt (zb. auf unsigned char beim packetPuffer, weil sonst negative Werte ankamen). Schaut so weit gar nicht schlecht aus:
Booting openmili2
Ethernet connected
# OpenMiLight Receiver/Transmitter starting
Contents: 45 0 55
Write : B8 63 D2 0 0 3 1
.
Contents: C5 0 55
Write : B8 63 D2 AF 0 13 2
Contents: 4E 1A 55
Write : B8 63 D2 AF C1 E 3
Contents: 45 0 55
Write : B8 63 D2 AF C1 3 4
Contents: C5 0 55
Write : B8 63 D2 AF C1 13 5
Contents: 4E 1A 55
Write : B8 63 D2 AF C1 E 6
Contents: 45 0 55
Write : B8 63 D2 AF C1 3 7
Contents: C5 0 55
Write : B8 63 D2 AF C1 13 8
Contents: 4E 1A 55
Write : B8 63 D2 AF C1 E 9
Contents: 45 0 55
Write : B8 63 D2 AF C1 3 A
Contents: C5 0 55
Write : B8 63 D2 AF C1 13 B
Contents: 4E 1A 55
Write : B8 63 D2 AF C1 E C
Contents: 45 0 55
Write : B8 63 D2 AF C1 3 D
Contents: C5 0 55
Write : B8 63 D2 AF C1 13 E
.
Contents: 4E 1A 55
Write : B8 63 D2 AF C1 E F
Contents: 45 0 55
Write : B8 63 D2 AF C1 3 10
Contents: C5 0 55
Write : B8 63 D2 AF C1 13 11
Contents: 4E 1A 55
Write : B8 63 D2 AF C1 E 12
.
Contents: 45 0 55
Write : B8 63 D2 AF C1 3 13
Contents: C5 0 55
Write : B8 63 D2 AF C1 13 14
Contents: 4E 1A 55
Write : B8 63 D2 AF C1 E 15
.
Contents: 45 0 55
Write : B8 63 D2 AF C1 3 16
Contents: C5 0 55
Write : B8 63 D2 AF C1 13 17
Contents: 4E 1A 55
Write : B8 63 D2 AF C1 E 18
Contents: 45 0 55
Write : B8 63 D2 AF C1 3 19
Contents: C5 0 55
Write : B8 63 D2 AF C1 13 1A
Contents: 4E 1A 55
Write : B8 63 D2 AF C1 E 1B
Contents: 45 0 55
Write : B8 63 D2 AF C1 3 1C
Contents: C5 0 55
Write : B8 63 D2 AF C1 13 1D
Contents: 4E 1A 55
Write : B8 63 D2 AF C1 E 1E
Contents: 45 0 55
Write : B8 63 D2 AF C1 3 1F
Contents: C5 0 55
Write : B8 63 D2 AF C1 13 20
Contents: 4E 2 55
Write : B8 63 D2 AF 81 E 21
Contents: 45 0 55
Write : B8 63 D2 AF 81 3 22
Contents: C5 0 55
Write : B8 63 D2 AF 81 13 23
Contents: 4E 2 55
Write : B8 63 D2 AF 81 E 24
Contents: 46 0 55
Write : B8 63 D2 AF 81 4 25
Contents: 46 0 55
Write : B8 63 D2 AF 81 4 26
Contents: 45 0 55
Write : B8 63 D2 AF 81 3 27
Contents: C5 0 55
Write : B8 63 D2 AF 81 13 28
Contents: 4E 1A 55
Write : B8 63 D2 AF C1 E 29
Contents: 45 0 55
Write : B8 63 D2 AF C1 3 2A
Contents: C5 0 55
Write : B8 63 D2 AF C1 13 2B
Contents: 4E 1A 55
Write : B8 63 D2 AF C1 E 2C
................
Pairing geht trotzdem nicht (hab zwei Leuchtmittel getestet, mit der Fernbedienung gehts, mit dem Sketch nicht :-( )
Kannst Dir das bitte mal ansehen? Vielleicht hab ich noch wo einen Denkfehler. Ach ja, ich hab auch zwei verschiedene nRF24 Chips getestet und die Stromversorgung über Kondensator gemacht - das sollte also eigentlich passen?!
BTW: Wie genau hast Du das mit dem Sniffen gemacht? Vielleicht komm ich hiermit was auf die Spur, indem ich den Output von dem Sketch mit dem Output der Fernbedienung vergleiche...
Cheers,
Pula
Also das sieht auf dem ersten Blick ok aus. Sniffen ist Prinzip ganz einfach z.b. mit dem MQTT sketch, der wertet die HF Signale aus, allerding nur das Milight Protokoll, also genau genommen kein richtiges sniffen.
Sent from my iPad using Tapatalk
OK, danke!
Werde mir den Sketch mal ansehen - ich brauch eh nur das Milight-Protokoll momentan ;-)
Sketch für Ethernet-Bridge (W5100-shield) ist fertig.
Werde ihn schka17 schicken und ihn bitten, den im 1. Beitrag anzuhängen...
Funktioniert bei mir in fhem mit wifilight und milight parallel (getestet momentan mal mit einer RGBW-Birne).
Achtung - damit das funktioniert, muß in der MyConfig.h
#define SOFTSPI
gesetzt sein!!!!
Pin-Belegung im Sketch.
Cheers,
Pula
Hmm....
ich habe als MS-Gateways zwei Raspis am laufen, da ich mit dem Etherne-GW nicht zufrieden war (Stabilität). Ich frage mich grad, ob es möglich wäre, an einem Raspi gleichzeitig MS-GW und Wifilight-Steuerung zu betreiben.... Muss ich mir mal ansehen. Würde die laufende Hardware verringern....
Cheers,
Pula
Zitat von: pula am 28 Dezember 2016, 13:50:01
Sketch für Ethernet-Bridge (W5100-shield) ist fertig.
Werde ihn schka17 schicken und ihn bitten, den im 1. Beitrag anzuhängen...
Funktioniert bei mir in fhem mit wifilight und milight parallel (getestet momentan mal mit einer RGBW-Birne).
Achtung - damit das funktioniert, muß in der MyConfig.h
#define SOFTSPI
gesetzt sein!!!!
Pin-Belegung im Sketch.
Cheers,
Pula
Ist hochgeladen
Sent from my iPad using Tapatalk
Super, dank Dir!
Cheers,
Pula
Wenn ihr das MS Gateway als Bridge definiert, nehmt ihr dann verschiedene Ports? Oder wie definiert man 4 Bridges auf eine ip?
Die Slots 5-8 bei RGBWW sind denk ich nicht veränderbar oder?
Grüße
Matze
Zitat von: smoudo am 28 Dezember 2016, 22:53:53
Wenn ihr das MS Gateway als Bridge definiert, nehmt ihr dann verschiedene Ports? Oder wie definiert man 4 Bridges auf eine ip?
Die Slots 5-8 bei RGBWW sind denk ich nicht veränderbar oder?
Grüße
Matze
Ja genau, über die Ports, mit dem Port wird dann auch die ID der Remotecontrol erzeugt. Die Ports sind im sketch änderbar, man kann es auch noch erweitern. Also wenn du mehr als 16 devices getrennt steuern willst entweder den sketch erweitern oder bei der 2.bridge andere ports verwenden.
Sent from my iPad using Tapatalk
Hört sich gut an! Verwendest du port 8899 aufsteigend dafür?
Geflasht wird das Ganze normal über die IDE mit esp Settings oder?
Viele Grüße
Matze
Es sind die Ports 8899 - 8896 :-)
Habe das mysensors board mit dem Sketch stabil laufen!
Nach anfänglichen Problemchen mit der Ide läuft alles!
Was das ganze ein wenig trübt ist die Reichweite und das
ich seitdem noch ein zusätzliches wlan vom esp aufgespannt habe!
Kann man das zusätzliche wlan Netz deaktivieren ohne
den kompletten esp lahmzulegen?
Grüße
Matze
Hab das Problem lösen können!
Wen der zusätzliche AP auch ärgert einfach die
Zeile im Sketch ergänzen:
WiFi.mode(WIFI_STA);
Grüße
Matze
Hallo zusammen,
ich versuche gerade, die Version 5 des Sketches mit einem Hexenmeister-Gateway zum Laufen zu bringen.
Irgendwie klappt das aber nicht. Ich habe das Gefühl, dass das Gateway immer rebootet, sobald ich ihm einen Befehl schicke. Normalerweise leuchtet die blaue LED des ESP und die rote LED auf der Gateway-Platine. Wenn ich z. B. ein "set on" schicke, flackern die LEDs kurz und gehen dann alle kurz aus und wieder an.
Und bei meiner Bulb kommt natürlich nichts an.
So ist das Ganze im FHEM definiert:
defmod milight MilightBridge 192.168.1.28
attr milight checkInterval 10
attr milight event-on-change-reading state
attr milight protocol udp
attr milight sendInterval 100
defmod licht MilightDevice RGBW milight 5
Hat jemand einen Tipp für mich, an was das liegen könnte?
Viele Grüße
Leo
Hallo Leo, es fehlt z.b. Die Portnummer, ich bin mir nicht sicher ob ohne Angabe der standardport 8899 verwendet wird, ich habe die Bridge so definiert
defmod MiLightBridge1 MilightBridge 192.168.255.18:8899
zur weiteren Fehlersuche lese bitte mit einem Terminalprogramm den Output des USB Ports aus
Edit: Wenn du keine Rückmeldung der FB über MQTT benötigst dann nimm die Version 4
Sent from my iPad using Tapatalk
Gibt es irgendwo eine Liste welche Libs alle Nachinstalliert werden müssen? Ich bekomme nur einen Haufen Kompilerfehler und blick nicht mehr durch.
Zitat von: gloob am 23 Januar 2017, 07:55:12
Gibt es irgendwo eine Liste welche Libs alle Nachinstalliert werden müssen? Ich bekomme nur einen Haufen Kompilerfehler und blick nicht mehr durch.
Einiges :-)
Am besten im Programm und in den Fehlermeldungen schauen was oben alles inkludiert werden soll und dann über den Library-Manager nachinstallieren. Irgendwann gehts dann durch.
Hallo schka17,
den Port nimmt er meines Wissens als Default.
Hab jetzt mal die 4er Version geflasht und den Monitor mitlaufen lassen:
Connecting to blau
..
Booting openmili2
WiFi connected
IP address:
192.168.1.28
# OpenMiLight Receiver/Transmitter starting
****************** hier hab ich im FHEM ein "set licht on" gemacht *******************
Contents: 45 0 55
Write : B0 63 D2 0 0 3 1
Soft WDT reset
ctx: cont
sp: 3ffef970 end: 3ffefcb0 offset: 01b0
>>>stack>>>
3ffefb20: 3fffdab0 00000000 3fffd9d0 402077c0
3ffefb30: 40106afc 3ffeeab4 3ffee934 40207810
3ffefb40: 00000000 3ffeeab4 3ffee934 402077c0
3ffefb50: 3ffee8f8 0000000e 3ffee934 40207810
3ffefb60: 3ffee8f8 000000ff 3ffee934 40207a66
3ffefb70: 3ffee8f8 00000030 3ffee934 40207ab0
3ffefb80: 3ffee8f8 00000030 3ffee934 40207bce
3ffefb90: 3ffee8f8 fffffffc 00000000 40207c13
3ffefba0: 00000000 3fffdad0 000000aa 40206b44
3ffefbb0: dc00aea4 0c00b064 903a0d08 35350000
3ffefbc0: 00000000 00000000 00000000 3144fffe
3ffefbd0: 00000001 3ffee903 000095cb 00000000
3ffefbe0: 0000000b 3fffdad0 3ffeec80 00000063
3ffefbf0: 3ffee8b8 00000007 3ffeebc4 00000063
3ffefc00: 3ffee8e8 3ffee8d8 00000001 40206635
3ffefc10: 3ffee8b8 3ffee8d8 00000007 4020666c
3ffefc20: 3fffdad0 00000007 3ffeebc4 4020709a
3ffefc30: 000000d2 00000002 3ffee8f8 40206cba
3ffefc40: 3ffe86e8 00000000 00000000 3ffeec80
3ffefc50: 3fffdad0 00000000 3ffeec78 40207170
3ffefc60: 3ffe8680 00000000 000003e8 402065a8
3ffefc70: 3ffeea4c 3fff0bd4 3ffeebc4 40206ea5
3ffefc80: 00000000 00000000 00000001 3ffeec80
3ffefc90: 3fffdad0 00000000 3ffeec78 4020945c
3ffefca0: feefeffe feefeffe 3ffeec90 40100718
<<<stack<<<
ets Jan 8 2013,rst cause:2, boot mode:(3,7)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v09f0c112
~ld
ø
Connecting to blau
..
Booting openmili2
WiFi connected
IP address:
192.168.1.28
# OpenMiLight Receiver/Transmitter starting
Die Arduino IDE hat mich auch fast um den Verstand gebracht!
Zum Erfolg kam ich mit einer älteren mysensors und Esp lib.
Wieso und warum weiß ich leider nicht. Irgendwann nach dem
Gefühlt 1000. kompilieren lief es durch! Ich denk vom esp sind
verschiedene Versionen unterwegs!
Grüße
Matze
Deswegen, fände ich es super, wenn es ein Paket aller benötigter Libs hier geben würde.
Zitat von: limats am 23 Januar 2017, 21:17:25
Hallo schka17,
den Port nimmt er meines Wissens als Default.
Hab jetzt mal die 4er Version geflasht und den Monitor mitlaufen lassen:
Connecting to blau
..
Booting openmili2
WiFi connected
IP address:
192.168.1.28
# OpenMiLight Receiver/Transmitter starting
****************** hier hab ich im FHEM ein "set licht on" gemacht *******************
Contents: 45 0 55
Write : B0 63 D2 0 0 3 1
Soft WDT reset
ctx: cont
sp: 3ffef970 end: 3ffefcb0 offset: 01b0
>>>stack>>>
3ffefb20: 3fffdab0 00000000 3fffd9d0 402077c0
3ffefb30: 40106afc 3ffeeab4 3ffee934 40207810
3ffefb40: 00000000 3ffeeab4 3ffee934 402077c0
3ffefb50: 3ffee8f8 0000000e 3ffee934 40207810
3ffefb60: 3ffee8f8 000000ff 3ffee934 40207a66
3ffefb70: 3ffee8f8 00000030 3ffee934 40207ab0
3ffefb80: 3ffee8f8 00000030 3ffee934 40207bce
3ffefb90: 3ffee8f8 fffffffc 00000000 40207c13
3ffefba0: 00000000 3fffdad0 000000aa 40206b44
3ffefbb0: dc00aea4 0c00b064 903a0d08 35350000
3ffefbc0: 00000000 00000000 00000000 3144fffe
3ffefbd0: 00000001 3ffee903 000095cb 00000000
3ffefbe0: 0000000b 3fffdad0 3ffeec80 00000063
3ffefbf0: 3ffee8b8 00000007 3ffeebc4 00000063
3ffefc00: 3ffee8e8 3ffee8d8 00000001 40206635
3ffefc10: 3ffee8b8 3ffee8d8 00000007 4020666c
3ffefc20: 3fffdad0 00000007 3ffeebc4 4020709a
3ffefc30: 000000d2 00000002 3ffee8f8 40206cba
3ffefc40: 3ffe86e8 00000000 00000000 3ffeec80
3ffefc50: 3fffdad0 00000000 3ffeec78 40207170
3ffefc60: 3ffe8680 00000000 000003e8 402065a8
3ffefc70: 3ffeea4c 3fff0bd4 3ffeebc4 40206ea5
3ffefc80: 00000000 00000000 00000001 3ffeec80
3ffefc90: 3fffdad0 00000000 3ffeec78 4020945c
3ffefca0: feefeffe feefeffe 3ffeec90 40100718
<<<stack<<<
ets Jan 8 2013,rst cause:2, boot mode:(3,7)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v09f0c112
~ld
ø
Connecting to blau
..
Booting openmili2
WiFi connected
IP address:
192.168.1.28
# OpenMiLight Receiver/Transmitter starting
Das schaut nicht gut aus, scheint als würde der reboot durch das schreiben=zugriff auf nrf ausgelöst.
Hast du sicherheitshalber schon mal ausprobiert ob der mysensor sketch auf deinem Gateway funktioniert? Dann würde ich mal davon ausgehen dass die HW ok ist. Ansonsten könnte ich mir nur mehr vorstellen dass es eine Inkompatibilität von Libraries ist. ich bin leider im moment beruflich unterwegs und nächstes Wochenende steht der Austausch meiner Heizung an, daher bin ich Moment zeitlich etwas eingeschränkt, ich versuche mal die Versionen die ich verwende zu dokumentieren.
Sent from my iPad using Tapatalk
@smoudo @gloob, siehe oben, ich versuche mal meine verwendeten versionen zu dokumentieren, und ja, mich treibt diese Arduino IDE auch manchmal zum verzweifeln, habe im moment 4 verschiedene IDE' mit unterschiedlichen Versionen für die unterschiedlich Anwendungen, find ich zum kotzen aber es gelingt mir nicht anders.
Sent from my iPad using Tapatalk
Ich schau die Tage mal nach meinen versionsständen die zum Erfolg geführt haben! HW ist bei mir ein mysensors SMD Gateway vom Hexenmeister.
Grüße
Matze
Arduino IDE: 1.6.12
ESP8266 Version 1.0.0
ESP8266_Basic-master
ESP8266WiFi 1.0.0
MySensors 2.1.0
Ich hoffe ich habe keine vergessen. Damit läuft das Mysensors Gateway in Verbindung mit dem openmili
Sketch einwandfrei!
Grüße
Matze
Im Moment ist das Ganze ein ziemlich zusammengehaxter Softwarehaufen. Tut was er soll und läuft, mir gefällts ausserordentlich!
Besteht Interesse das wir das ganze Projekt etwas
seriöser gestalten und ein wenig strukturieren (ohne gleich einen Verein zu gründen! ;) )
- Programm
- Schaltung
- Beispiele
- Gehäuse
An einem Programm wäre ich sehr interessiert.
@smoudo: Meinst du wirklich ESP8266 Version 1.0? Da ist die aktuelle ja 2.3.0.
Aber das könnte natürlich ein Grund sein, weshalb es bei mir nicht funktioniert.
Zitat von: schka17 am 23 Januar 2017, 22:02:04
Das schaut nicht gut aus, scheint als würde der reboot durch das schreiben=zugriff auf nrf ausgelöst.
Schau auch mal nach der Spannungsversorgung. Könnte sein dass die Spannung zusammenbricht wenn der nrf senden soll und gleichzeitig der esp noch per WLAN was absetzen muss. Ein dickerer Kondensator zwischen GND und VCC wirkt manchmal Wunder.
Die Versionen die ich erfolgreich einsetze:
Arduino 1.6.12
Libraries
RF24 by TMRh20 V 1.1.7
Mysensors 2.0.0
ESP8266Wifi V1.0.0
Wifi Built-In by Arduino 1.2.7
Boards
esp8266 2.3.0
Alle die Probleme beim kompilieren haben, finden unter https://goo.gl/R29sxq eine portable Version der Arduino IDE inkl. der notwendigen Bibliotheken
@limats
Hab die versionsstände aus der Ide ausgelesen!
Ich hatte auch wild rumprobiert bis das funktionierte!
Mit den geposteten versionsständen läufts bei mir sauber durch!
Grüße
Matze
Ich habe heute Nacht nach einem Fritzbox update selbige leider neu aufsetzen müssen und jetzt passen die
ganzen ESP IP`s nicht mehr! >:(
Hat jemand eine Idee wo man von DHCP auf Statische IP umstellen und die Einstellungen vornehmen kann.
Habe im Sketch nichts gesehen was mit DHCP zu tun haben könnte.
Grüße
Matza
Zitat von: smoudo am 28 Januar 2017, 11:11:26
Ich habe heute Nacht nach einem Fritzbox update selbige leider neu aufsetzen müssen und jetzt passen die
ganzen ESP IP`s nicht mehr! >:(
Hat jemand eine Idee wo man von DHCP auf Statische IP umstellen und die Einstellungen vornehmen kann.
Habe im Sketch nichts gesehen was mit DHCP zu tun haben könnte.
Grüße
Matza
Das solltest du doch auf der fritzbox auch machen können, wäre das nich einfacher?
Sent from my iPad using Tapatalk
Hat jetzt geklappt mit dem IP fest zuweisen auf der box. Das Problem ist, wenn es die Fritzbox mal wieder verhaut, habe ich das selbe Problem. Hatte ein Backup von den Einstellungen gezogen was sich aber nicht zurückspielen lässt >:(
Grüße
Matze
Zitat von: smoudo am 28 Januar 2017, 12:24:01
Hat jetzt geklappt mit dem IP fest zuweisen auf der box. Das Problem ist, wenn es die Fritzbox mal wieder verhaut, habe ich das selbe Problem. Hatte ein Backup von den Einstellungen gezogen was sich aber nicht zurückspielen lässt >:(
Grüße
Matze
Hilft dir jetzt wahrscheinlich nicht, aber wenn ich mir so die Probleme mit diesem Fritz Zeugs in den verschiedenen Foren so durchlese, dann wundert es mich schon, dass das jemand kauft, ich nehme im Netzwerkbereich lieber ein paar Euros mehr in die Hand erspare mir da viel Ärger.
Aber super dass es wieder geht.
Sent from my iPad using Tapatalk
ich muss sagen, bisher hatte ich mit allen Boxen die im Bekanntenkreis laufen keinerlei Probleme.
Die 6.80er Software von dieser Woche scheint aber ein DNS Problem zu haben und das nicht nur auf den neuen Boxen.
Geschäftlich haben wir Lancom und Securepoint Boxen am rennen. Auch nicht wirklich problemlos und der preisliche Unterschied sind auch mehr als ein paar Euro ;) aber dafür passt der Support!
Was für eine Box schlägst Du vor im Bereich: VDSL, WLAN, SIP Telefonie über Telekom?
Grüße
Matze
Moin,
kann man eigentlich auch den PA_LEVEL der NRF ändern wie bei MySensors?
EDIT: Scheint schon auf MAX zu stehen, ein Kondensator hat geholfen...
Bei mir läuft es grundsätzlich mit folgendem Umfeld, die Reichweite könnte aber etwas besser sein (diverse NRF-chips getestet):
Arduino IDE 1.8.0 @ Linux
Libraries
RF24 by TMRh20 V 1.2.0
Mysensors 2.1.1
ESP8266Wifi V1.0.0
Wifi Built-In by Arduino 1.2.7
Boards
esp8266 2.3.0 (Wemos D1 mini)
Gruß, Beta-User
Zitat von: smoudo am 28 Januar 2017, 16:43:09
ich muss sagen, bisher hatte ich mit allen Boxen die im Bekanntenkreis laufen keinerlei Probleme.
Die 6.80er Software von dieser Woche scheint aber ein DNS Problem zu haben und das nicht nur auf den neuen Boxen.
Geschäftlich haben wir Lancom und Securepoint Boxen am rennen. Auch nicht wirklich problemlos und der preisliche Unterschied sind auch mehr als ein paar Euro ;) aber dafür passt der Support!
Was für eine Box schlägst Du vor im Bereich: VDSL, WLAN, SIP Telefonie über Telekom?
Grüße
Matze
Hallo Matze,
Naja, solange man ein Tablet, telephon einen Laptop und vielleicht ein bischen streaming hat, wirds wohl funktionieren, sobald du aber beginnst das Netzwerk etwas auszubauen um es sicherer, besser, schneller zu machen... da habe ich schon lustige Sachen gelesen. Kann sein dass da im Bereich VDSL Unterschiede gibt zwischen AT und DE, ich habe einen Zyxel SBG3500 , das ist ein dual WAN Router, ich habe hier zuhause nur ADSL, VDSL sollte aber auch gehen. Hatte zwar schon Diskussionen mit der Telekom weil ich mein eigens Endgerät angeschlossen habe, aber da es mehrfach vorgekommen ist das am Telekom modem neue FW oder Konfigänderungen vorgenommen wurden wonach nichts mehr funktioniert hat, steht das in der Ecke. Und wenn die Telekom das nicht haben will dann sollen Sie sich den ADSL ...., das zweite WAN ist eine LTE Router. Im Wlan Bereich setzt ich nur mehr Ubiquity ein, und wenn ich einen neuen Router oder Switches benötigen würde, dann auch von Ubiquity. Leider habe ich aber gerade in smart managed Switches von TP-LINK investiert, bin zwar von Preis/Leistungsverhältnis begeistert (also Geschwindigkeit, VLAN, QOS usw), aber der Unify Controller mit der FHEM Einbindung und Mgt. App am Ipad , das ist schon wirklich gut und einfach zu bedienen. Der Zyxel ist halt ein bisschen nerdig, war aber damals der einzige der alles konnte. Mit IP Telefonie habe ich keine Erfahrung
Sent from my iPad using Tapatalk
Bei uns bekommst du die iP Telefonie vom rosa Riesen aufgezwungen. Und die einzige Möglichkeit die anständig funktioniert und nicht speedport heißt ist momentan die Fritz. Das Telekom sip verhält sich merkwürdig. Hab es mit nem sip analog wandler nicht zum laufen bekommen! Und eine Telefonanlage
ist bei uns zuhause ein wenig übertrieben bei einem Endgerät!
Das ubiquity finde ich auch interessant gerade in Bezug auf wlan handover! Wieviele AP hast du davon in Betrieb? Die Gab es als ich mir das angeschaut hatte aber nur auf 2,4ghz Basis. Sollte mittlerweile auch anders sein.
Grüße
Matze
Zitat
Das ubiquity finde ich auch interessant gerade in Bezug auf wlan handover! Wieviele AP hast du davon in Betrieb? Die Gab es als ich mir das angeschaut hatte aber nur auf 2,4ghz Basis. Sollte mittlerweile auch anders sein.
Eigentlich waren drei geplant (die bestehenden drei auszutauschen), Ein Grund war auch das roaming zu ermöglichen, habe mal mit einem angefangen, was soll ich sagen, der deckt den kompletten Bereich ab, ich werd im Frühjahr noch einen für den Garten kaufen, aber im Haus deckt der eine AP alles ab, vom Keller bis zum Dachboden, dafür hatte ich vorher drei AP's im Einsatz.
Sent from my iPad using Tapatalk
Guten Morgen zusammen,
so ist das wirklich eine super Sache, die Multi-Bridge funktioniert tadellos und deckt auch (mit Kondensator und PA-verstärkter Variante) das ganze Haus bequem ab!
Eine Frage habe ich noch:
Eigentlich sollte doch auch die Vers. 4 an der seriellen Schnittstelle empfangene Fernbedienungscodes ausgeben, oder? Das funktioniert bei mir leider nicht.
Testweise habe ich daher den openmili-Sketch von Henryk auf ein USB-GW geflasht (die Hardware an sich als GW funktioniert) und es dabei mit den beiden aktuellsten RF24-libs (1.2.0 und 1.1.7) probiert. Ich sehe auch an dem seriellen GW weder Fernbedienungscodes, noch reagiert der Arduino auf Signale von meiner Eigenbau-Bridge (die funktioniert als Sender tadellos, s.o.).
Hat mir dazu jemand einen Tip?
Danke vorab,
Beta-User
Hallo Beta-User,
Mit dem openmili sketch kannst du nur senden, senden & empfangen mit dem mqtt sketch
Sent from my iPad using Tapatalk
Hallo schka17,
Danke für den Stups, irgendwie ist das nicht selbsterklärend, dass man das "if (receiving)" deaktivieren bzw. auskommentieren muß, um zu empfangen ???.
Habe das "if" jetzt in dem 4-er Sketch wieder (de-)aktiviert, dann klappt das mit dem empfangen auch mit diesem Sketch. Jetzt muß ich mich nur irgendwie noch dran machen, das in ein "echtes" MySensors-GW mit integriertem "Infrarot"-Empfänger zu verwandeln (MQTT verwende ich auf absehbare Zeit nicht).
Dann könnte das Rückwärtsmappen von FB-Signalen nach FHEM meine erste eigene Perl-Funktion werden, bin schon gespannt, ob das klappt...
Gruß, Beta-User
Hallo
Habe bei mir den mqtt Scetch in Verwendung.. wie ist das mqtt device in fhem dazu einzurichten bei mir wird nichts empfangen
so sieht das bei mir aus
Internals:
.autoSubscribeExpr ^ESPopenmili_1\/Milight\/Remote\/([^/]+)$
.autoSubscribeTopic ESPopenmili_1/Milight/Remote/+
CFGFN
DEF ESPopenmili_1
IODev Mqtt
NAME milightlicht
NOTIFYDEV ESPopenmili_1
NR 1554
STATE subscription acknowledged
TYPE MQTT_DEVICE
qos 0
retain 0
Readings:
2017-01-29 17:51:01 transmission-state subscription acknowledged
Message_ids:
Sets:
subscribe:
ESPopenmili_1/Milight/Remote/+
ESPopenmili_1/Milight/Address
ESPopenmili_1/Milight/Brightness
ESPopenmili_1/Milight/CMD
ESPopenmili_1/Milight/Color
ESPopenmili_1/Milight/Counter
ESPopenmili_1/Milight/Type
subscribeExpr:
^ESPopenmili_1\/Milight\/Remote\/([^/]+)$
^ESPopenmili_1\/Milight\/Address$
^ESPopenmili_1\/Milight\/Brightness$
^ESPopenmili_1\/Milight\/CMD$
^ESPopenmili_1\/Milight\/Color$
^ESPopenmili_1\/Milight\/Counter$
^ESPopenmili_1\/Milight\/Type$
Subscribereadings:
ESPopenmili_1/Milight/Address Address
ESPopenmili_1/Milight/Brightness Brightness
ESPopenmili_1/Milight/CMD CMD
ESPopenmili_1/Milight/Color Color
ESPopenmili_1/Milight/Counter Counter
ESPopenmili_1/Milight/Type Type
Attributes:
IODev Mqtt
autoSubscribeReadings ESPopenmili_1/Milight/Remote/+
room Mqtt
stateFormat transmission-state
subscribeReading_Address ESPopenmili_1/Milight/Address
subscribeReading_Brightness ESPopenmili_1/Milight/Brightness
subscribeReading_CMD ESPopenmili_1/Milight/CMD
subscribeReading_Color ESPopenmili_1/Milight/Color
subscribeReading_Counter ESPopenmili_1/Milight/Counter
subscribeReading_Type ESPopenmili_1/Milight/Type
WEB Server
Username Milight
Password
Accesspoint
SSID:ESP8266_742619
Password :ESP8266config
WiFi
SSID :FRITZ!Box 7490
Password :xxxxxxxx
MQTT
Broker IP:192.168.178.108
Port: 1883
Devicename:ESPopenmili_1
UpdateServer
Server IP:
FilePath:
Mein bulbs funktionieren so weit nachdem ich das nodemcu tauschen mußte weil durch ständige restarts
kein pairen möglich war (china ware)
Nur mein LED Stripe läßt sich nicht pairen oder kann das nicht funktionieren
Ines
Hi schka,
mir ist aufgefallen, daß ich bei dem Ethernet-Sketch im Kommentar mit der Verkabelung einen Verdreher drin habe. Kannst Du das bitte in dem Sketch im ersten Post richtigstellen? So muß es heißen:
/*
* Attention:
* for use with W5100 Ethernet-shield you have to uncomment
* //#define SOFTSPI in Mysensors/Myconfig.h !!!!!
* nRF24L01+ Arduino UNO (W5100)
* VCC 3.3V
* CE 9
* CSN/CS 10
* SCK 14 (=A0)
* MISO 16 (=A2)
* MOSI 15 (=A1)
* GND GND GND
*/
Danke und cheers,
Pula
Hallo Zusammen,
bin gerade mit der IDE am verzweifeln. Und zwar wenn ich eine Überprüfung starte bekomme ich immer die Fehlermeldung
fatal error: FS.h: No such file or Directory
Auch bei der Portable Vesion... :-(
Bin Neu mit dem Thema und hoffe da hat einer eine Idee ..:-(
Gruß
Markus
Da fehlt die benötigte Library
Sent from my iPad using Tapatalk
ja stimmt :-)
Ist das erste mal das ich mich damit beschäftige. War eine frische Installation und habe nicht gedacht das da so viele Libarys fehlen.
Hab die alle mal anhand der Fehlermeldungen nachinstalliert und nun läuft es durch.
Muss eigentlich ausser den Wifi Settings noch etwas eingetragen werden in dem Sketch?
Wie sieht das denn mit den Schnittstellen und Board.Settingsim IDE aus? Gibt es da irgendwoeine Übersicht wie ich was da Einstellen muss als Anfänger :-)
Gruß
Markus
Ich gehe davon aus du sprichst vom openmili sketch ohne MQTT, dort musst du nur die WIFI Einstellungen machen solange du nichts am Pinlayout verändern möchtest.
natürlich, du musst das Port über das du flashen willst, einstellen, und auch welches Board du verwendest, diese Informationen hast aber nur du, da gibt es keine Übersicht dazu.
Zitat von: pula am 30 Januar 2017, 20:07:38
Hi schka,
mir ist aufgefallen, daß ich bei dem Ethernet-Sketch im Kommentar mit der Verkabelung einen Verdreher drin habe. Kannst Du das bitte in dem Sketch im ersten Post richtigstellen? So muß es heißen:
/*
* Attention:
* for use with W5100 Ethernet-shield you have to uncomment
* //#define SOFTSPI in Mysensors/Myconfig.h !!!!!
* nRF24L01+ Arduino UNO (W5100)
* VCC 3.3V
* CE 9
* CSN/CS 10
* SCK 14 (=A0)
* MISO 16 (=A2)
* MOSI 15 (=A1)
* GND GND GND
*/
Danke und cheers,
Pula
den Beitrag hatte ich übersehen, ist jetzt erledigt
Also das flashen hat nun funktioniert. Habe auch entsprechend nun vier Bridges in FHEM angelegt. Nun bin ich mal gespannt wie es mit es mit dem Pairing klappt... :-) Kann man nicht irgendwie die Konfig von einem bestehenden Pairing (orginal Bridge)"umbiegen" ?
Gruß
Markus
so das Pairing habe ich auch soweit hinbekommen... Jedoch musste ich das Unpairing erst über die App machen, da ich es mit der Fernbedienung nicht hinbekommen hab. Nun klappt aber die Fernbedienung nicht mehr... Wie lerne ich die denn zusätzlich an?
Also das beides klappt FHEM und FB
Vergesst es... war zu blöd... ;-)
funzt nun mit der ersten Testlampe :-)
Gruß
Markus
Zitat von: Markus. am 21 Februar 2017, 12:58:09
Also das flashen hat nun funktioniert. Habe auch entsprechend nun vier Bridges in FHEM angelegt. Nun bin ich mal gespannt wie es mit es mit dem Pairing klappt... :-) Kann man nicht irgendwie die Konfig von einem bestehenden Pairing (orginal Bridge)"umbiegen" ?
Gruß
Markus
Jein, die pairing Information ist ja nur im Empfänger (Lampe/Stripecontroller) gespeichert. Was man allerdings schon machen kann, im Sketch die Adresse der FB verwenden. Dann kann man pairen/unpairen alles über die FB machen und bedienen dann über den openmili controller ohne pairen zu müssen.
Zitat von: schka17 am 21 Februar 2017, 14:43:35
im Sketch die Adresse der FB verwenden.
mhh - wie kriege ich denn die Adresse der FB raus?
Zitat von: bloodybeginner am 21 Februar 2017, 17:04:02
mhh - wie kriege ich denn die Adresse der FB raus?
z.B. siehe weiter oben: https://forum.fhem.de/index.php?topic=58742.msg572622#msg572622
Kann man eigentlich in dem 4gw sketch irgenwas einstellen um die Funkleistung des Moduls zu erhöhen ?
Irgendwie habe ich das Gefühl das die Funkleistung ein wenig geringer ist als bei der milight v4 bridge.
Gruß
Markus
Ich habe eben mal ein FHEM Update gemacht und bekomme seit dem folgende Meldung
Stehlampe: unknown IODev Milight02 specified
Gruppe1: unknown IODev Milight02 specified
Deckenlampe: unknown IODev Milight02 specified
Die Bridge ist aber erreichbar, ist definiert und funktioniert soweit. Das Attribut IODEVind den Miglight devices wirdnach dem Neustart auch gelöscht (nicht in der Fhem.cfg sondern nur im Device). Die Lampen funkionieren dann logischerweise nicht mehr. Nach dem ich das Attribut wieder setzte in den Devices klappen auch wieder die Lampen obwohl die SlotEintäge in der entsprechenden Bridge leer sind.
Ist eigentich die Reihenfolge der Definitionen in der Fhem.cfg wichtig? Ich habe gesehen, das die Devices vor den Bridges definiert sind...
Jetzt weiß ich nicht ob das am letzten Update liegt oder an der Bridge selber. Gestern hatte ich dieses Problem noch nicht nach diversen Neustarts.
Gruß
Markus
Es ist leider so, auch wenn man immer im Forum liest man soll die fhem.cfg nicht bearbeiten, man braucht das auch nie. Stimmt nicht, es gibt ein paar Ausnahmen, das IO Device muss vor dem Gerät dass das IO Device verwendet, geladen sein. Ist nicht bei allen Modulen so, aber bei Milightbridge ist es so. Man sieht auch die entsprechenden Meldungen im Logfile beim starten.
Sent from my iPad using Tapatalk
Ja genau, vertausche die Reihenfolge in der Config.
Entweder über edit files (nachdem das global attribut geändert wurde, damit du das dort durchführen kannst) oder du machst fhem shutdown und editierst von Aussen mit einem Editor Deiner Wahl:
sudo cp /opt/fhem/fhem.cfg /opt/fhem/fhem.cfg.vorAenderung
sudo nano /opt/fhem/fhem.cfg
sudo service fhem start
Wichtig ist, dass Geräte die genutzt werden vorher auch schon definiert sind. Konkret erst die Bridge dann die Devices ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, MySensor, HomeBridge, Presence, Bravia, ...
Stimme schka17+RaspiLED zu.
Das Problem kann man umgehen, indem man die Definition der vorhandenen GW's schlicht ändert...
Zitat von: Markus. am 21 Februar 2017, 21:00:16
Kann man eigentlich in dem 4gw sketch irgenwas einstellen um die Funkleistung des Moduls zu erhöhen ?
Softwaremäßig ist das bereits auf voller Sendeleistung eingestellt. Es gelten aber die allgemeinen Regeln für die nRF's wie hier beschrieben: https://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowT:
ZitatOne user said, "Just Solder a 100nF ceramic cap across the gnd and 3.3v pins direct on the nrf24l01+ modules!" Some have used a 1uF to 10uF capacitor.
In die se Richtung geht auch das, was dazu bei MySensors steht.
Ich erreiche sehr gute Reichweiten mit einem Modul mit externer Antenne.
Gruß, Beta-User
Danke euch....klappt nun nachdem ich die bridges vor den devices lade ... macht ja auch irgendwo sinn;-)
@beta-user
Was für ein modul ist das denn genau mit der externen antenne? Glaube nicht das ich auf mein Modul eine externe antenne machen kann. Naja gaaaaanz langsam versteh ich den kram aber nur gaaanz langsam 😂
Gruß
Markus
Zitat von: Markus. am 22 Februar 2017, 08:59:19
Was für ein modul ist das denn genau mit der externen antenne? Glaube nicht das ich auf mein Modul eine externe antenne machen kann.
Ne, Du brauchst dazu ein anderes Modul, Abbildungen siehe wikispaces (sorry, der Link war nicht vollständig: https://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo).
Zitat von: Markus. am 22 Februar 2017, 08:59:19
Was für ein modul ist das denn genau mit der externen antenne? Glaube nicht das ich auf mein Modul eine externe antenne machen kann.
bei den Bridges mit gesockelten nRF kann man einfach ein nRF-Modul mit PA+LNA aufstecken (so etwas: https://www.aliexpress.com/item/1sets-Special-promotions-1100-meter-long-distance-NRF24L01-PA-LNA-wireless-modules-with-antenna/32330779943.html).
Aber Vorsicht, damit kann eine maximal erlaubte Sendeleistung überschritten werden.
ahhh suupi so langsam kann ich dem folgen.... :-)
Also würde das Funkmodul zu meinen auf den Board drauf passen aber man könnte es auch in Verbindung mit einem NodeMCU zum Gateway machen..? Also z.b.Nodemcu + NRF = Gateway
Sorry für die blöden Fragen.. ;-)
Gruß
Markus
Zitat von: Markus. am 22 Februar 2017, 10:25:53
Also würde das Funkmodul zu meinen auf den Board drauf passen aber man könnte es auch in Verbindung mit einem NodeMCU zum Gateway machen..? Also z.b.Nodemcu + NRF = Gateway
Jep. Man könnte auch grundsätzlich mit Drähten aus NodeMCU und Funkmodul ein Gateway zusammenstecken. Damit es (vor allem mit Verstärker) stabil läuft, brauchst Du noch Stützkondensatoren. Incl. Taster und LEDs sind nicht wirklich wichtig.
Zitat von: hexenmeister am 22 Februar 2017, 10:11:25
bei den Bridges mit gesockelten nRF kann man einfach ein nRF-Modul mit PA+LNA aufstecken (so etwas: https://www.aliexpress.com/item/1sets-Special-promotions-1100-meter-long-distance-NRF24L01-PA-LNA-wireless-modules-with-antenna/32330779943.html).
Ich habe jetzt so ein Ding mit Verstärker hier angeschlossen (an einem ESP-12). Bisher ist die Leistung enttäuschend. Man muss oft mehrmals drücken damit die grad mal 2m entfernte Testbirne reagiert. Das Kommando kommt am ESP-Modul noch an, die blaue Betriebs-LED flackert. Ob es dann gesendet wird kann man schlecht feststellen, ich gehe aber davon aus.
Wodran könnte das liegen?
Hast du einen Kondensator an zwischen VCC und GND gelötet?
Danke für den Tipp, das hat geholfe!
Den kleinen Kondensator habe ich jetzt auch noch eingelötet, seitdem scheint es wesentlich besser zu laufen.
Vorher hatte ich schon einen dicken 100uF-Elko direkt hinter dem Spannungswandler, das reicht anscheinend nicht immer aus um die Spannung zu stützen.
Hier sind noch ein paar Tipps um dem Kasten mehr Leistung zu verpassen:
http://blog.blackoise.de/2016/02/fixing-your-cheap-nrf24l01-palna-module/
(http://blog.blackoise.de/2016/02/fixing-your-cheap-nrf24l01-palna-module/)
Die Schirmung mit der Folie könnte man auf jeden Fall mal probieren.
Hallo
Bei mir passen die Farben nicht mehr rot ist jetzt pink und gelb geht ins orange wie ist das anzupassen ? ???
Zitat von: inesa394 am 07 März 2017, 13:59:14
Hallo
Bei mir passen die Farben nicht mehr rot ist jetzt pink und gelb geht ins orange wie ist das anzupassen ? ???
Das dürfte aber nichts mit der bridge zu tun haben ... ???
vg
joerg
Gibt es jemanden bzw. eine Quelle hier zum ordern für fertig geflashte "Bridges"?
Zitat von: Gunther am 09 März 2017, 20:47:51
Gibt es jemanden bzw. eine Quelle hier zum ordern für fertig geflashte "Bridges"?
Müssen da nicht WLAN Zugangsdaten erst 'hineincompiliert' werden? Dann geht das schlecht mit fertig compiliert.
Ja, soweit habe ich das auch verstanden. Diese Sicherheitslücke würde ich ggf. in Kauf nehmen und demjenigen meine Daten geben.
Kann Dir das Ding mit dem openmili Sketch Flashen.
Läuft dann im fhem mit milightbridge / Device.
Voraussetzung: du bist mit einer SMD verdrahteten
Variante zufrieden und Hexenmeister hat noch was
auf Lager was er mir als Ersatz zukommen lassen kann!
Kosten: Bridge vom Hexer + Versand von mir
Grüße
Matze
Hallo Matze,
das klingt super!
Ich habe beim hexenmeister welche geordert. Sobald die da sind, versuche ich einen zu Dir kommen zu lassen.
Kannst Du mir Deine Daten per PN schicken.
Danke schonmal und viele Grüße
Gunther
'n Abend!
Habe zwei neue ESP-Module (und eigentlich auch paar, die schon irgendwo eingesetzt wurden, müssten auch in Ordnung sein, müssten aber getestet werden), dazu noch eine SMD-Version von nRF und genügend bedrahtete...
Reichen Dir zwei Module? Möchtest Du SMD, oder 'normale' nRF haben? Wenn letzteres, dann gesockelt oder fest eingelötet?
Grüße
Alexander
Wenn Du willst kann Alex zu mir schicken und ich Schicks weiter.
Ansonsten Rest per pm.
Grüße
Matze
Zitat von: hexenmeister am 10 März 2017, 23:13:24
'n Abend!
Habe zwei neue ESP-Module (und eigentlich auch paar, die schon irgendwo eingesetzt wurden, müssten auch in Ordnung sein, müssten aber getestet werden), dazu noch eine SMD-Version von nRF und genügend bedrahtete...
Reichen Dir zwei Module? Möchtest Du SMD, oder 'normale' nRF haben? Wenn letzteres, dann gesockelt oder fest eingelötet?
Grüße
Alexander
Puh, Du hast hier einen puren Anfänger...
Was sind denn die Vor- und Nachteile außer der Größe von SMD / Verdrahtet?
Was bedeutet gesockelt/ eingelötet?
Ich würde 2 Module nehmen. Du könntest beide zu Matze schicken. Dann kann er mir eins flashen und das andere einfach so weiterschicken.
Was bekommst Du?
Hallo
Kann man sich hier in die Reihe der Hoffenden Besteller einreihen?
Wenn ja hätte ich gerne einen Satz - vornehmlich als LAN Version
Stenny
Gesendet von iPad mit Tapatalk
@Gunther: Konditionen wie immer. Ich schreibe dir heute Abend eine PM.
Zitat von: stenny73 am 11 März 2017, 15:06:38
Hallo
Kann man sich hier in die Reihe der Hoffenden Besteller einreihen?
Wenn ja hätte ich gerne einen Satz - vornehmlich als LAN Version
Mit einer LAN Version kann ich leider nicht dienen. WLAN auf Basis ESP-13e/f Moduls wäre möglich, muss aber erst schauen, ob ich noch ESPs rumliegen habe.
Zitat von: hexenmeister am 11 März 2017, 15:30:46
Mit einer LAN Version kann ich leider nicht dienen. WLAN auf Basis ESP-13e/f Moduls wäre möglich, muss aber erst schauen, ob ich noch ESPs rumliegen habe.
Dann sag einfach an wenn du alles hast, vor allem was du bekommst.....
Gesendet von iPad mit Tapatalk
Ich habe gerade nur handvoll Bauteile ;)
Reichen mindestens für zwei WLAN-to-nRF-Bridges, vlt. auch mehr. Muss ich schauen. Die Bridges können als MySensors-Gateway oder als MiLight-Bridge genutzt werden, je nach Firmware (die man selbst mit einem UART-Adapter aufspielen muss).
Ich betreibe kein Geschäft, von Zeit zu Zeit verkaufe ich nur die überflüssigen Platinen (die Fertigung lohnt sich erst ab einer bestimmten Anzahl).
Heute hätte ich paar WLAN-onewire Bridges und werde noch (auf eine ausdrückliche Anfrage) NRF-Bridges bauen. Details sind in jeweiligen threads in Marktplatz zu finden.
Zitat von: Gunther am 11 März 2017, 12:46:43
Was sind denn die Vor- und Nachteile außer der Größe von SMD / Verdrahtet?
Was bedeutet gesockelt/ eingelötet?
Vorteile SMD-Version: Extrem flach
Die verdrahtete Standartversion, wenn festgelötet, ist auch kaum höher. Beide passen in ein Hammond 1551H Gehäuse (muss natürlich ein Loch für MicroUSB-Stecker gebohrt werden).
Vorteile gesockelte bedrahtete Version: nRF kann ausgetauscht werden, z.B. durch eine Version mit Antenne und Verstärker.
Das ist dann aber in jedem Fall zu hoch fürs Hammond-Gehäuse.
Kurze Frage zur Auswahl des Sketches bzgl. MQTT vs. ohne:
Habe ich es richtig verstanden, dass mit MQTT nur die Fernbedienung empfangen werden kann aber nicht gesendet?
Oder wo sind die Vor- und Nachteile des jeweiligen Sketches?
Hast du schon einen mqtt Broker laufen?
Hab das ganze testweise mit nem sonoff Dual
am laufen. Brauchst du aber bei milight ansich nicht.
Man könnte die gesendeten Zustände der Fernbedienung
auswerten für die Zustände. Bringt dir aber nichts wenn
Normal per klassischen Lichtschalter geschaltet wird.
Grüße
Matze
Zitat von: smoudo am 12 März 2017, 21:22:36
Hast du schon einen mqtt Broker laufen?
Was heißt das? ::)
Ich habe die milight-Steuerungen für die LED-Streifen hinter Homematic hängen:
Hardwaretaster --> Homematicaktor --> Trafo --> Milight-Steuerung --> LED-Streifen
Fernbedienungen würde ich gerne als Alternative zu meinen FHEM-Tablets nutzen.
Was empfiehlt sich? Mit oder ohne MQTT?
Mqtt Broker ist das Bindeglied zwischen der Bridge und fhem. In wie weit die Umsetzung funktioniert bei der Milight Geschichte kann ich Dir leider nicht sagen. Habe keine Fernbedienungen am laufen. Verwende den openmili Sketch um insgesamt 4 Bridges zu emulierten. Fhem seitig nehmen ich Milight Bridge / Device. Die Umsetzung mit homematic funktioniert schonmal ohne Mqtt.
Grüße
Matze
2 Punkte habe ich nicht verstanden:. Sorry, vielleicht sind meine Fragen von meinem kleinen Wissensstand geprägt... ::)
ZitatFhem seitig nehmen ich Milight Bridge / Device.
Du nutzt hardwareseitig zusätzlich noch die Original Milight Bridges?
Die Umsetzung mit homematic funktioniert schonmal ohne Mqtt.
Was hat das Ganze nun mit homematic zu tun?
Alexander flasht mir die Dinger gleich. Für mich stellst sich nun die Frage, womit.
Gunther,
wenn Du bislang kein MQTT nutzt, nimm einfach die "normale" Version... Alles andere findet sich.
Gruß,
Beta-User
Nope ich nutze nur noch die mysensors Bridge und emuliere mit dem Sketch 4 Bridges über die Ports. So können 16 Gruppen über 1 Bridge gesteuert werden!
Du kannst mit dem homematic Schalter ohne Mqtt oder sonstige helferlein direkt über fhem
Die Milight Bridge ansteuern!
Wenns Alex flasht ist doch top! Sparst dir 1x Versand
Grüße
Matze
Habe gerade ein Modul geflasht und 4 Bridges angelegt.
define milight1 MilightBridge 192.168.0.105
attr milight1 checkInterval 10
attr milight1 event-on-change-reading state
attr milight1 icon cul_usb
attr milight1 port 8899
attr milight1 protocol udp
attr milight1 sendInterval 100
define milight2 MilightBridge 192.168.0.105
attr milight2 checkInterval 10
attr milight2 event-on-change-reading state
attr milight2 icon cul_usb
attr milight2 port 8898
attr milight2 protocol udp
attr milight2 sendInterval 100
define milight3 MilightBridge 192.168.0.105
attr milight3 checkInterval 10
attr milight3 event-on-change-reading state
attr milight3 icon cul_usb
attr milight3 port 8897
attr milight3 protocol udp
attr milight3 sendInterval 100
define milight4 MilightBridge 192.168.0.105
attr milight4 checkInterval 10
attr milight4 event-on-change-reading state
attr milight4 icon cul_usb
attr milight4 port 8896
attr milight4 protocol udp
attr milight4 sendInterval 100
Scheint zu funktionieren. Nur Lampen habe ich gerade nicht zur Hand.
Die Dinger müssen doch eindeutige IDs haben? Kann man sie irgendwie beeinflüsssen? Damit die gleiche ID wie bei einer (vorhandenen) Fernbedienung verwendet wird?
Die ID wird im Sketch festgelegt (pro port eine ID).
Wenn man dieselbe ID verwenden wollte wie eine vorhandene FB, müßte man das vor dem Flashen berücksichtigen...
Danke, dann muss ich mir den Quellcode zu Gemüte führen ;D
(am besten sogar konfigurierbar machen, im WebConfig, oder so...)
Apropos Webconfig: Nachdem ich meine WLAN-Config in der Webconfig nochmal eingetragen hatte, konnte sich die Bridge nicht mehr mit meinem WLAN-AP verbinden. Ich bin noch nicht ganz dahinter gestiegen, weil zuerst im Log angezeigt wird, dass sich die Bridge mit dem AP verbunden hat und eine IP per DHCP bekommen hat (von "espClient.start_WiFi_connections(); ??" . Danach ist sie auch anpingbar, aber das Web-Interface nicht erreichbar. Im Log kommt nur noch "Connecting to ..."
Dann hab ich bei der Bridge mit esptool.py den Flash-Speicher gelöscht, neu die FW openmili5_OTA_MQTT eingespielt und in der WebConfig nur den MQTT-Host eingetragen und schon lief alles und ich konnte meine Lampen anlernen.
Das Problem hatte ich bei 2 Bridges.
@schka17 hast du die Files evtl. bei github? Dann könnte ich Änderungen besser nachvollziehen.
Vielen Dank aber schon mal. Damit kann ich meine Milight-Bridge v4 vielleicht entsorgen.
Hab meine Lampen mit der original bridge+app unpaired und
mit dem Gateway neu gepaired! War relativ fummelig!
Grüße
Matze
Zitat von: Tom71 am 14 März 2017, 09:36:28
@schka17 hast du die Files evtl. bei github? Dann könnte ich Änderungen besser nachvollziehen.
@schka17 hast du ggf. was dagegen, wenn ich die Sourcen in mein GitHub hochlade?
Noch ne Frage...
Der Sketch ist ein 1-zu-1 Ersatz für die originalbridge, oder? Für weiße und rgbw Lampen?
Hintergrund der Frage: im Sketch, wo das Paket zum versenden zusammen gebaut wird, steht im ersten byte 0xb0 und im Kommentar b0 für weiß und b8 für rgbw.
Muss ich das für bunte Lampen ändern?
Wenn nur ent- oder weder geht, brauche ich beide Lösungen, da ich ich WW-LEDs und RGBWW-LEDs einsetze. ;-)
ich rechne eig. noch damit, dass es beides gleichzeitig geht, wollte nur sicherheitshalber nachfragen und verstehen :)
OHNE Gewähr:
Ich habe eben mal den Sketch aufgemacht, den ich geflasht hatte und habe das B0 eher nicht geändert. Das Steuern der RGBW's geht damit...
Auch bei der "orginalen" RGBW-Fernbedienung von Hendry kam ein "B0": https://hackaday.io/project/5888-reverse-engineering-the-milight-on-air-protocol/log/18529-command-and-control.
So was habe ich auch vermutet, war mir aber nicht sicher. Da RGBW damit geht, haben wir ja die Bestätigung :)
Zitat von: hexenmeister am 13 März 2017, 22:03:51
Nur Lampen habe ich gerade nicht zur Hand.
Wenn Du möchtest stelle ich Dir welche leihweise zur Verfügung
vg
joerg
Danke fürs Angebot.
Ich habe mir schon seit geraumer Zeit eine Bridge, eine FB und Lampen in E27 und gu10 besorgt. Nur komme ich erst am WE an die Sachen ran. Dann kann ich hoffentlich austesten. Bis jetzt habe ich nur eine Bridge geflasht und ins fhem eingebunden. Das ging so weit. Wenn ich jedoch ein Milight_Device (geht ja erstmal auch ohne Lampe) angelegt habe und set pair eingegeben habe, kamen haufenweise Fehlermeldungen im log. Irgendwas stimmt bei meinem fhem noch nicht.
So, ich habe nun die Devices hier und eines mal mit Strom versorgt, sowie als Bridge mit der IP in FHEM definiert.
Nun 2 Fragen dazu:
1) Wie bekomme ich meine noch ungepairten RBGWW Steuerungen eingebunden?
2) Wie bekomme ich meine bereits mit den original Milight-Steuerungen gepairten RBGWW Steuerungen eingebunden?
Das Wechseln der Bridge in der fhem.cfg funktioniert wie weiter oben geschrieben schonmal nicht.
Freue mich über einen Hinweis. Bin leider weder im Wiki noch im Forum fündig geworden.
In der commandref ist ja beschrieben, wie ein Device eingebunden wird. Dafür muss ich es ja irgendwie ansprechen (beim Original mit der App pairen und dann einbinden). Die App scheint ja hier die Bridge nicht zu finden.
Habe ähnliche Fragen...
Habe die Sourcen aus dem Forum compiliert und geflasht. FHEM meldet Bridge connected. MQTT-Version gibt auch die Daten raus, wenn ich etwas mit der Original-Fernbedienung etwas mache. Ich bekomme aber meine Lampe nicht aus dem FHEM gepaired oder gesteuert.
Beim set ML_TEST kommt im Log:
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/31_MilightDevice.pm line 961.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (961)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $h in numeric lt (<) at ./FHEM/31_MilightDevice.pm line 1668.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1668)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $h in numeric gt (>) at ./FHEM/31_MilightDevice.pm line 1669.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1669)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $h in numeric lt (<) at ./FHEM/31_MilightDevice.pm line 1670.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1670)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $h in numeric gt (>) at ./FHEM/31_MilightDevice.pm line 1671.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1671)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $s in numeric lt (<) at ./FHEM/31_MilightDevice.pm line 1672.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1672)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $s in numeric gt (>) at ./FHEM/31_MilightDevice.pm line 1673.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1673)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $v in numeric lt (<) at ./FHEM/31_MilightDevice.pm line 1674.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1674)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $v in numeric gt (>) at ./FHEM/31_MilightDevice.pm line 1675.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1675)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $h in numeric lt (<) at ./FHEM/31_MilightDevice.pm line 1668.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1668)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $h in numeric gt (>) at ./FHEM/31_MilightDevice.pm line 1669.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1669)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $h in numeric lt (<) at ./FHEM/31_MilightDevice.pm line 1670.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1670)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $h in numeric gt (>) at ./FHEM/31_MilightDevice.pm line 1671.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1671)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $s in numeric lt (<) at ./FHEM/31_MilightDevice.pm line 1672.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1672)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $s in numeric gt (>) at ./FHEM/31_MilightDevice.pm line 1673.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1673)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $v in numeric lt (<) at ./FHEM/31_MilightDevice.pm line 1674.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1674)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $v in numeric gt (>) at ./FHEM/31_MilightDevice.pm line 1675.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1675)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $h in numeric lt (<) at ./FHEM/31_MilightDevice.pm line 1668.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1668)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $h in numeric gt (>) at ./FHEM/31_MilightDevice.pm line 1669.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1669)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $h in numeric lt (<) at ./FHEM/31_MilightDevice.pm line 1670.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1670)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $h in numeric gt (>) at ./FHEM/31_MilightDevice.pm line 1671.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1671)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $s in numeric lt (<) at ./FHEM/31_MilightDevice.pm line 1672.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1672)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $s in numeric gt (>) at ./FHEM/31_MilightDevice.pm line 1673.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1673)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $v in numeric lt (<) at ./FHEM/31_MilightDevice.pm line 1674.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1674)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
2017.03.18 19:20:31 1: PERL WARNING: Use of uninitialized value $v in numeric gt (>) at ./FHEM/31_MilightDevice.pm line 1675.
2017.03.18 19:20:31 1: stacktrace:
2017.03.18 19:20:31 1: main::__ANON__ called by ./FHEM/31_MilightDevice.pm (1675)
2017.03.18 19:20:31 1: main::MilightDevice_ValidateHSV called by ./FHEM/31_MilightDevice.pm (2188)
2017.03.18 19:20:31 1: main::MilightDevice_CmdQueue_Add called by ./FHEM/31_MilightDevice.pm (965)
2017.03.18 19:20:31 1: main::MilightDevice_RGBW_Pair called by ./FHEM/31_MilightDevice.pm (627)
2017.03.18 19:20:31 1: main::MilightDevice_Set called by fhem.pl (3307)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (1651)
2017.03.18 19:20:31 1: main::DoSet called by fhem.pl (1683)
2017.03.18 19:20:31 1: main::CommandSet called by fhem.pl (1108)
2017.03.18 19:20:31 1: main::AnalyzeCommand called by fhem.pl (977)
2017.03.18 19:20:31 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (274)
2017.03.18 19:20:31 1: main::telnet_Read called by fhem.pl (3312)
2017.03.18 19:20:31 1: main::CallFn called by fhem.pl (675)
Definitionen:
define ML_TEST MilightDevice RGBW milight1 5
attr ML_TEST IODev milight1
attr ML_TEST devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
attr ML_TEST event-on-change-reading state,transitionInProgress
attr ML_TEST lightSceneParamsToSave hsv
attr ML_TEST restoreAtStart 1
attr ML_TEST room Test
attr ML_TEST webCmd on:off:dim:hue:night:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffff00
attr ML_TEST widgetOverride RGB:colorpicker,RGB
define milight1 MilightBridge 192.168.0.82
attr milight1 checkInterval 10
attr milight1 event-on-change-reading state
attr milight1 port 8899
attr milight1 protocol udp
attr milight1 sendInterval 100
Irgendwo fehlt mir noch das Verständniss :(
Hallo,
eigentlich, sollte es so funktionieren (zumindest hat es bei mir so funktioniert):
-Birnen waren an der Original FB gepairt
(geht auch ohne vorher mit der FB zu pairen, nur hatte ich dann Probleme nach Fhem die Birnen mit der FB zu pairen)
-Birnen Stromlos gemacht
-Strom wieder eingeschaltet und sofort ein paar mal auf "on" in Fhem-Device geklickt.
Die Birnen haben dann mit grünen Licht quittiert.
Gruß Holger
Hmm, klappt bei mir nicht.
Habt Ihr noch einen Tipp?
Habe auch versucht die Steuerung einzuschalten und dann das vorher definierte Device mit
set DEVICE pair
zu pairen.
Die Bridge (list) sieht so aus:
Internals:
CHANGED
Clients :MilightDevice:
DEF 192.168.0.128
HOST 192.168.0.128
INTERVAL 100
NAME milightfrickel1
NR 255
NTFY_ORDER 50-milightfrickel1
PORT 8899
SENDFAIL 0
STATE ok
TYPE MilightBridge
cmdLastSent 1489864470.41291
cmdQueueLock 0
0:
1:
2:
3:
4:
5:
NAME eg_ez_mi_LED
6:
7:
8:
Matchlist:
1:MilightDevice .*
Readings:
2017-03-18 20:17:55 sendFail 0
2017-03-18 20:11:24 slot0
2017-03-18 20:11:24 slot1
2017-03-18 20:11:24 slot2
2017-03-18 20:11:24 slot3
2017-03-18 20:11:24 slot4
2017-03-18 20:11:24 slot5 eg_ez_mi_LED
2017-03-18 20:11:24 slot6
2017-03-18 20:11:24 slot7
2017-03-18 20:11:24 slot8
2017-03-18 20:17:55 state ok
cmdQueue:
Helper:
Attributes:
checkInterval 10
event-on-change-reading state
protocol udp
room IOs
sendInterval 100
Das Device (list) schaut so aus:
Internals:
DEF RGBW milightfrickel1 5
INIT 1
IODev milightfrickel1
LEDTYPE RGBW
NAME eg_ez_mi_LED
NR 1657
NTFY_ORDER 50-eg_ez_mi_LED
SLOT 5
SLOTID 5
STATE on 36
TYPE MilightDevice
Readings:
2017-03-18 20:14:28 brightness 36
2017-03-18 20:13:09 brightness_on 36
2017-03-18 20:14:28 discoMode 0
2017-03-18 20:14:28 discoSpeed 0
2017-03-18 20:14:28 hsv 0,0,36
2017-03-18 20:14:28 hue 0
2017-03-18 20:14:27 previousState 0,0,0
2017-03-18 20:14:28 rgb 5B5B5B
2017-03-18 20:14:28 saturation 0
2017-03-18 20:14:28 state on 36
2017-03-18 20:14:28 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 1489864468.31116
targetVal 36
whiteLevel 10
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 milightfrickel1
devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
event-on-change-reading state,transitionInProgress
lightSceneParamsToSave brightness
restoreAtStart 1
room Esszimmer
webCmd on:off:dim:ct:night
EDIT: auch mit
set DEVICE pair 9
(9 für 9 Sekunden) und danach Einschalten funktioniert es nicht.
@Gunther:
Eigentlich sollte das pairen mit jedem Befehl klappen, der direkt nach der Spannungszufuhr an die Bulb/den LED-Controller geschickt wird. Ich nehme bevorzugt die Schaltfläche für "ffffff" (weiß, ganz hell), die kann man leichter mehrfach klicken als den set-Befehl umständlich auszuwählen...
Bei einzelnen Bulbs hatte ich da aber auch Probleme beim Anlernen. Abhilfe war dann das vollständige unpair des betreffenden Leuchtmittels (mit einer FB, gleich nach Stromzufuhr länger auf den "all-on"-Button drücken).
Gruß, Beta-User
Danke. Leider packe ich es noch nicht.
Vermutlich ist es besonders schwierig wegen des vorgeschalteten Homematic-Aktors.
Ich habe es nun auch mit einem notify versucht. Leider vergeblich.
define pairmilight notify eg_ez_LEDStreifen:on sleep 0.5;; set eg_ez_mi_LED on
wobei
eg_ez_LEDStreifen = Homematic Aktor
eg_ez_mi_LED = Milight Steuerung
Kann ich feststellen, ob mein neues Device (Bridge) funktioniert?
...keine schlechte Idee mit dem notify, sollte eigentlich gehen, unterschiedliche Zeiten hast Du vermutlich schon versucht...
Die Bridge zu testen, ist schwierig ohne gepairtes Leuchtmittel und Änderung des geflashten Codes. Bist Du sicher, dass es die "alte" Generation Milihts ist, die Du da hast (im Wiki v.a. unter V4 abgebildet)? Neuere MiLights haben längere Codes und sind meines Wissens nach insgesamt nicht mit den Modulen usw. kompatibel.
Funktioniert eine der normalen Bridges?
Bei mir ging es auch erst nachdem die leuchtmittel unpaired waren. Hab ich mithilfe der original Bridge + app gemacht.
Pairing:
Hab auch Strom drauf und den on Befehl gesendet. Lampen bestätigen bei mir mit 3x rot blinken
Eure Definitionen sehen ok aus!
Grüße
Matze
Ich musste nicht erst unpairen. Nur stromlos machen, wieder einschalten und in Fhem auf on geklickt. Danach blinkte die LED-Lampe.
Ich habe diese hier:
https://www.amazon.de/gp/product/B00NRL73UE
https://www.amazon.de/gp/product/B0102AYR1K
Vielleicht klappt das Senden nicht. Wie könnte man denn das überprüfen? Zweites GW?
Meine Konfig:
defmod MilightBridge MilightBridge 192.168.0.85:8899
attr MilightBridge checkInterval 10
attr MilightBridge event-on-change-reading state
attr MilightBridge protocol udp
attr MilightBridge room Server
attr MilightBridge sendInterval 100
setstate MilightBridge ok
setstate MilightBridge 2017-03-20 07:51:37 sendFail 0
setstate MilightBridge 2017-03-18 09:03:37 slot0
setstate MilightBridge 2017-03-18 09:03:37 slot1
setstate MilightBridge 2017-03-18 09:03:37 slot2
setstate MilightBridge 2017-03-18 09:03:37 slot3
setstate MilightBridge 2017-03-18 09:03:37 slot4
setstate MilightBridge 2017-03-18 09:03:37 slot5 Milight_Leselampe
setstate MilightBridge 2017-03-18 09:03:37 slot6 Kuechenlampe
setstate MilightBridge 2017-03-18 09:03:37 slot7
setstate MilightBridge 2017-03-18 09:03:37 slot8
setstate MilightBridge 2017-03-20 07:51:37 state ok
Sollte man denn jetzt mit MilLightbridge oder mit WifiLight arbeiten? Funktionieren tut anscheinend beides, ich habe allerdings das Gefühl das Wifilight mit der selbstgebauten Bridge besser arbeitet. Habe bisher allerdings nur 2 Birnen gepairt.
Es ist schon sonderbar, dass Gunther und ich anscheinend das gleiche Problem haben...
Woran könnte es liegen?
- Hardware-Problem.
Halte ich eher für unwahrscheinlich, da bei vielen Anderen ja die gleiche Hardware offensichtlich gut funktioniert.
- Software.
Kann sein, ich habe ja auch Gunthers Hardware geflasht, möglicherweise habe ich falschen Sketch etc. Das wäre leicht behebbar, ich müsste nur verstehen, was falsch ist.
Was geht:
- Ich kann die in diesem Thread zu findende Sketches kompilieren und flashen. Sie scheinen auch zu laufen.
- Ich kann mit dem MQTT-Sketch die Daten sehen, die von meiner Originalfernbedienung gesendet werden (spricht auch eher für eine intakte Hardware).
Was geht nicht:
- Paaren und Steuern (ich habe jetzt mit einer MiLight-Lampe und MilLightbridge-FHEM-Modul probiert)
Was ich probieren will:
- WifiLight
- zweites Gateway aufbauen und versuchen dieses per MQTT-Bridge zu "belauschen", ob da auch was ankommt. vlt. kann ich sehen, was dort falsch läuft.
Könnte mir jemand (wer erfolgreich eine solche Bridge im Einsatrz hat) schreiben, welche von den Sketches er genommen hat?
(@Gunther: sollte eine Neubefüllung nötig sein, machen wir das entweder per Post, oder ich versuche Dir eine fertig kompilierte Datei zu erstellen, die dann quasi "mit einem Klick" geflasht werden kann. Dafür wird nur ein billiges USB-Adapter benötigt, diesen könnte ich Dir auch zur Verfügung stellen. Sollte gar nichts klappen, nehme ich die Bridges selbstverständlich gegen Erstattung des Kaufpreises zurück.)
Also bei mir hat die Power Buchse des FUT038 einen Wackelkontakt... Der Stecker sitzt sehr locker drin...
Das Paring klappt nachdem etwas nachgeholfen habe.
Zitat von: hexenmeister am 20 März 2017, 12:40:20
Könnte mir jemand (wer erfolgreich eine solche Bridge im Einsatrz hat) schreiben, welche von den Sketches er genommen hat?
Ich habe die V4 seit einigen Wochen drauf (kann aber sein, dass ich den Sketch dahingehend umgebaut habe, dass ich die FB-Signale an der seriellen Ausgabe erhalte; sollte für das Problem hier aber irrelevant sein). Geflascht aber auf einem China-Wemos D1 mini, der nRF in der Version mit externer Antenne (PA+LNA?). Was Adaptermodul, Kondensator oä. angeht, habe ich die HW grade nicht verfügbar.
EDIT: Arduino-IDE 1.8.0 (offizielle Version von arduino.cc auf einem 64-bit ubuntu)
Wenn Du die FB-Signale empfangen kannst, spricht das dafür, dass
a) das keine neue HW ist (neuere Modelle nutzen längere Codes, die openmili nach meiner Kenntnis (noch) nicht lesen kann)
b) die Verkabelung usw. i.O. ist. Problem könnte allenfalls die Funkreichweite beim Senden sein (Kondensator/en hast Du aber ja in der Regel verbaut, bis 2m sollten aber auch ohne gehen und wieviel störungsfreien Strom der nRF bekommt, weißt Du besser...).
Das Pairen hat dann mit der ganz überwiegenden Zahl meiner Bulbs bzw. dem einen LED-Controller meistens gut funktioniert,
aber eben nicht bei allen, wobei das nach meinem Eindruck kein Reichweitenthema gewesen sein dürfte. Bei den "unwilligen" Bulbs (ca. 2 von 18) mußte ich erst ein globales unpair machen, was ich mit einer Fernbedienung erledigt habe. Danach ging es...
Die Bulbs selber habe ich seit mehr als 2 Jahren im Einsatz, die hängen alle auch hinter einem physischen Schalter. Von daher habe ich die Vermutung, dass die Bulbs einen Speicher haben für FB-Ids, der WLAN "mitschneidet" und irgendwann volläuft.
Was aber uU. eine Rolle spielen könnte:
Ich habe meine IDE vor nicht allzu langer Zeit aktualisiert und mit MySensors auch eine aktuelle Version der nRF-lib auf dem System installiert. Diese Fassung der lib sollte eigentlich nicht genutzt werden, sondern die modifizierte, die mit den Sketches hier ausgeliefert wird. Aber ob die IDE das so umgesetzt hat?
@hexenmeister:
ich bin mir ziemlich sicher, dass ich die Version openmili5_OTA_MQTT.7z aus dem ersten Eintrag genommen habe: https://forum.fhem.de/index.php?action=dlattach;topic=58742.0;attach=59974
Zum übersetzten hab ich die Arduino-IDE von der Dropbox genommen aus diesem Eintrag: https://forum.fhem.de/index.php/topic,58742.msg569250/topicseen.html#msg569250
Hab den 1. Sketch genommen fürs MS gateway
Grüße
Matze
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
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
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
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
@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
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.
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.
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
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...
Zitat von: hexenmeister am 22 März 2017, 20:08:30
Nur wie bringen ich dem Ding das Paaren bei...
Schon mit "rgb ffffff" versucht?
siehe hier https://forum.fhem.de/index.php?action=post;quote=502242;topic=58742.200;last_msg=609846 und die vorhergehenden paar Beiträge...
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
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
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
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
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
Hallo Heiko,
Das mit dem lilaton kann ich bestätigen, sowohl bei led stripes als auch bei RBG und RBGW Lampen. Ist mir noch nie aufgefallen da ich den reinen Rotton noch nie verwendet habe, kann nich sagen ob das aus dem Modul, der Bridge oder den Lampen kommt.
Disco mode habe ich noch nie verwendet.
Bin im moment aber leider beruflich und privat sehr ausgebucht, wenn ich mal Zeit finde werde ich das mal debuggen
Sent from my iPad using Tapatalk
Zitat von: heikoxxxx am 31 Mai 2017, 21:10:54
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
Hallo Heiko,
bin noch nicht dazugekommen mal die Funksignale zu sniffen, aber hab schnell mal ein bischen mit dem attribut colorcast herumgespielt.
Wenn ich den Wert auf
attr led colorCast-25,0,0,0,0,0
setze habe ich ein ein schönes sattes Rot.
Gruß
Karl
ich habe in der ganz aktuellen version von wifilight die defaults noch einmal angepasst. An den Funksignales sieht man das nicht.
Wenn jemand einen milight RGB(W) controller mit stripe betreibt müsste man das sehr gut sehen können. Bei Rot darf wirklich nur noch rot leuchten.
Unter den Lampen kann man das nicht ganz so exakt sehen weil die Milchglaskuppel das abschirmt. Wenn jamand vorschläge macht übernehme ich die gern.
Im modul steht das ca #3590
my $devRed = 168;
#my $devRed = 176;
my $devYellow = 134;
#my $devYellow = 144;
my $devGreen = 88;
#my $devCyan = 48;
my $devCyan = 56;
my $devBlue = 8;
my $devLilac = 208; #224
Für rot müsste man (bei colorcast 0) den Wert $devRed solange ein wenig justieren bis wirklich nur noch rot leuchtet. (g und b dann genauso)
vg
joerg
Hallo,
ich habe leider noch eine grundlegende Frage zum flashen. Ich krieg es nämlich nicht hin :(
Ich habe mir einen Bausatz v.1.5 vom Hexenmeister aufgebaut.
Jetzt wollte ich den Sketch "openmili_4_MS_GW" flashen. Nachdem ich mich erst mal durch gefühlte 100 Bibliotheken kämpfen musste und diese nachinstalliert habe, bekomme ich es zumindest schon mal kompiliert. Das war schon mal ein langer weg....
Aber beim Flashen komme ich nicht weiter. Wenn ich in der Arduino IDE "Hochladen" drücke bekomme ich folgende Fehlermeldungen:
Arduino: 1.8.3 (Windows 10), Board: "Generic ESP8266 Module, 80 MHz, 40MHz, QIO, 115200, 4M (1M SPIFFS), ck, Serial, All"
Archiving built core (caching) in: C:\Users\Dirk\AppData\Local\Temp\arduino_cache_740318\core\core_esp8266_esp8266_generic_CpuFrequency_80,FlashFreq_40,FlashMode_qio,UploadSpeed_115200,FlashSize_4M1M,ResetMethod_ck,Debug_Serial,DebugLevel_all______9bfc1086b29dccc360b763d584525162.a
Der Sketch verwendet 264073 Bytes (25%) des Programmspeicherplatzes. Das Maximum sind 1044464 Bytes.
Globale Variablen verwenden 36704 Bytes (44%) des dynamischen Speichers, 45216 Bytes für lokale Variablen verbleiben. Das Maximum sind 81920 Bytes.esptool v0.4.9 - (c) 2014 Ch. Klippel <ck@atelier-klippel.de>
setting board to ck
setting baudrate from 115200 to 115200
setting port from COM1 to COM4
setting address from 0x00000000 to 0x00000000
espcomm_upload_file
espcomm_upload_mem
setting serial port timeouts to 1000 ms
opening bootloader
resetting board
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
espcomm_send_command: receiving 2013 bytes of data
read 0, requested 1
error: failed reading byte
warning: espcomm_send_command: cant receive slip payload data
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
espcomm_send_command: receiving 2013 bytes of data
read 0, requested 1
error: failed reading byte
warning: espcomm_send_command: cant receive slip payload data
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
espcomm_send_command: receiving 2013 bytes of data
read 0, requested 1
error: failed reading byte
warning: espcomm_send_command: cant receive slip payload data
resetting board
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
espcomm_send_command: receiving 2013 bytes of data
read 0, requested 1
error: failed reading byte
warning: espcomm_send_command: cant receive slip payload data
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
espcomm_send_command: receiving 2013 bytes of data
read 0, requested 1
error: failed reading byte
warning: espcomm_send_command: cant receive slip payload data
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
espcomm_send_command: receiving 2013 bytes of data
read 0, requested 1
error: failed reading byte
warning: espcomm_send_command: cant receive slip payload data
resetting board
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
espcomm_send_command: receiving 2013 bytes of data
read 0, requested 1
error: failed reading byte
warning: espcomm_send_command: cant receive slip payload data
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
espcomm_send_command: receiving 2013 bytes of data
read 0, requested 1
error: failed reading byte
warning: espcomm_send_command: cant receive slip payload data
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
espcomm_send_command: receiving 2013 bytes of data
read 0, requested 1
error: failed reading byte
warning: espcomm_send_command: cant receive slip payload data
warning: espcomm_sync failed
error: espcomm_open failed
error: espcomm_upload_mem failed
error: espcomm_upload_mem failed
Hat jemand eine Idee was ich falsch mache?
Muss ich am Adapter etwas besonderes einstellen oder vorher mit dem Modul vom Hexenmeister noch etwas machen?
Danke
Eindeutig ein Problem mit der Verbindung.
Weder beim Modul, noch an den Einstellungen des UART-Adapters muss etwas geändert werden. Wichtig ist nur, dass dieser 3,3V-Pegel an die Signalleitungen legt! Auch die Versorgung des ESP-Chips darf nur 3,3V betragen. 5 Volt verträgt dieser nicht.
Anfangen sollte man erstmal damit, dass man die Meldungen über den Serialport ansieht. Auch ein neuer, ungeflashter ESP gibt was lesbaren von sich (Reset drücken). Wenn die Verbindung steht, dann mit dem Flashen versuchen. Evtl. sind einfach nur Leitungen RX/TX vertauscht (müssen zw. dem Adapter und dem Modul "über Kreuz" verbunden verden, also RX an TX und andersrum). Ich schliesse immer nur RX, TX und GND an den Andapter an und versorge gleichzeitig das Modul über USB. UART-Adapter liefern manchmal nicht gnug zum stabilen Betrieb von ESP.
Hallo,
also Rx und Tx habe ich schon gekreuzt dran. Das sollte passen. Ich habe die Versorgungsspannung auch über ein USB angelegt. Die 3,3V vom TTL Converter habe ich jetzt mal weggelassen. Jedoch immer noch der gleiche Fehler.
Wenn ich den COM port öffne und die Reset Taste drücke kommt bei mir eine wilde Zeichenkette an. ich habe es als Bild angehangen weil es bei Copy&Paste nicht ging.
Ist das so richtig?
Hi,
Ja das ist richtig, die wilde Zeichenkette ist eine andere Baudrate des Bootloaders und die wird dann wenn die Firmware bootet umgesetzt und er meldet sich richtig. Wenn Du sehen willst was er vorher schreibt musst du auf die andere Baudrate (9600 oder 115.200) gehen, dann wird aber die Ai Thinker eine wilde Zeichenfolge ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Hm, ok. Wie kann ich jetzt weiter vorgehen bei der Fehlersuche?
Gesendet von meinem VTR-L09 mit Tapatalk
Hi,
Hast Du mal die Tasten versucht:
• Reset drücken, halten
• Flash drücken, halten
• Reset loslassen
• Flash loslassen
• Flashprogramm starten
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Hallo,
habe es soeben probiert. Leider gleiche Fehlermeldung :(
Sollte denn im Seriell Monitor etwas unterschiedliches ankommen ob ich den Reset drücke oder Ihn in den Flash Modus mit der Flashtaste versetze? Da kommt nämlich immer das Gleiche.
Ich bin hier jetzt leicht am Verzweifeln.
Kann es an irgendwelchen Bibliotheken liegen?
Danke
Hi, Schau mal hier:
https://forum.fhem.de/index.php/topic,62083.msg534915.html#msg534915
Vielleicht eine eine andere BootFirmware?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Anscheinend kommt ESP nicht in Bootloader-Mode. Ich würde mal checken, ob die Lötstellen/Verbindungen zw. dem Pin (GPIO0), der Taste, dem Widerstand und GND in Ordnung sind. Miss mal, ob bei gedrückter Taste am GPIO0 GND-Pegel anliegt.
Hi,
daran hat es gelegen. Der GPIO0 wird bei gedrücktem Flash-Taster auf 1,66V gezogen, warum nicht auf 0V weiß ich noch nicht.
Wenn ich jedenfalls direkt Masse auf den GPIO0 lege, dann kann ich erfolgreich flashen. Zumindest laut IDE. Ich werde jetzt mal die Bridge und das Device in Fhem anlegen und versuchen meine RBGW controller zu pairn.
Und ich begebe mich mal auf die Suche nach dem Fehler auf dem Board.
Am Board selbst kann es ja nicht liegen das ist ja mehrfach im Einsatz von Dir Hexenmeister, oder hat das ein Bug den ich überlesen habe?
Danke
Zitat von: FEHMPiDi am 11 Juli 2017, 14:25:36
Am Board selbst kann es ja nicht liegen das ist ja mehrfach im Einsatz von Dir Hexenmeister, oder hat das ein Bug den ich überlesen habe?
Nein, diese Board-Revision (1.5) hat keine (bekannte) Bugs und funktioniert mehrfach einwandfrei. Natürlich kann ein Fertigungsproblem nicht ausgeschlossen werden, allerdings hatte ich bis jetzt nur eine von über 200 Platinen mit einem Fertigungsproblem (Kurzschluss zweier Leiterbahnen).
Hey, ist es ggf. möglich das mal ins WIKI aufzunehmen ?
Zitat von: lufi am 14 Juli 2017, 09:44:48
Hey, ist es ggf. möglich das mal ins WIKI aufzunehmen ?
Na klar: ein Wiki ist kein Autorensystem sondern lebt von der aktiven Mitarbeit der Nutzer, im folgenden "Du" genannt :)
https://wiki.fhem.de/wiki/FHEMWiki:%C3%9Cber_FHEMWiki
vg
joerg
Hallo zusammen,
Ich habe auch hexenmeisters board als milight bridge seit gut einem halben jahr laufen. Ich will / muss jetzt auf einen anderen raspi mit fhem umziehen. Wie sieht es eigentlich dann mit dem pairing der lampen aus? Muss ich die alle neu pairen oder kann man die bestehende konfig irgenwie auf den neuen Server umziehen?
Gruss
Markus
Das pairing zwischen Bridge und Lampe ist was anderes wie die Ansteuerung der Bridge von FHEM aus. Wenn du bei letzterem die config übernimmst (wifilight-definition bzw. milight_bridge/milight_device), ist alles im Butter ;) ...
Genial.. :-) das heisst ich könnte auf dem zweiten Fhem die ganze Konfig schon mal machen und ausprobieren ....
Gruss
Markus
Sollte sogar parallel gehen, ist nur eine UDP-message an bestimmte ports...
geht parallel. Aber Vorsicht: wenn beide gleichzeitig mit der bridge reden (stichwort transitions) gibt es murks
Ich hole den Beitrag aus dem März nochmal hoch. Mein Problem ist ja noch nicht gelöst.
@ Hexenmeister: Hast Du eine Lösung gefunden? Falls ja, wie bekomme ich die ebenfalls hin?
Zitat von: hexenmeister am 20 März 2017, 12:40:20
Es ist schon sonderbar, dass Gunther und ich anscheinend das gleiche Problem haben...
Woran könnte es liegen?
- Hardware-Problem.
Halte ich eher für unwahrscheinlich, da bei vielen Anderen ja die gleiche Hardware offensichtlich gut funktioniert.
- Software.
Kann sein, ich habe ja auch Gunthers Hardware geflasht, möglicherweise habe ich falschen Sketch etc. Das wäre leicht behebbar, ich müsste nur verstehen, was falsch ist.
Was geht:
- Ich kann die in diesem Thread zu findende Sketches kompilieren und flashen. Sie scheinen auch zu laufen.
- Ich kann mit dem MQTT-Sketch die Daten sehen, die von meiner Originalfernbedienung gesendet werden (spricht auch eher für eine intakte Hardware).
Was geht nicht:
- Paaren und Steuern (ich habe jetzt mit einer MiLight-Lampe und MilLightbridge-FHEM-Modul probiert)
Was ich probieren will:
- WifiLight
- zweites Gateway aufbauen und versuchen dieses per MQTT-Bridge zu "belauschen", ob da auch was ankommt. vlt. kann ich sehen, was dort falsch läuft.
Könnte mir jemand (wer erfolgreich eine solche Bridge im Einsatrz hat) schreiben, welche von den Sketches er genommen hat?
(@Gunther: sollte eine Neubefüllung nötig sein, machen wir das entweder per Post, oder ich versuche Dir eine fertig kompilierte Datei zu erstellen, die dann quasi "mit einem Klick" geflasht werden kann. Dafür wird nur ein billiges USB-Adapter benötigt, diesen könnte ich Dir auch zur Verfügung stellen. Sollte gar nichts klappen, nehme ich die Bridges selbstverständlich gegen Erstattung des Kaufpreises zurück.)
Ich habe mal eine Frage bezgl des Wifilight-Moduls.
Kann die Infos im Thread leider nicht finden.
Funktioniert das Wifilight-Modul mit der ESP-Bridge?
Ich kann im Wifilight-Modul ja keinen Port angeben und somit die 4 Bridges voneinander trennen.
Erkennt das Modul dies automatisch?
Geht es aktuell überhaupt mit dem Modul?
Milight-Device/Bridge soll ja nicht mehr erste Wahl sein da angeblich nicht mehr weiterentwickelt...
Vielen Dank für die Infos.
grtz
CmdA
Zitat von: Gunther am 19 Oktober 2017, 22:07:15
Ich hole den Beitrag aus dem März nochmal hoch. Mein Problem ist ja noch nicht gelöst.
@ Hexenmeister: Hast Du eine Lösung gefunden? Falls ja, wie bekomme ich die ebenfalls hin?
Musste ich kurz überlegen, was da mal war... Ich habe später die Idee MiLight zu verwenden komplett verworfen. Eine Lösung habe ich leider nicht. Irgendwie hatten wir scheinbar ein spezifisches, was sonst keiner kannte :/
Heißt das, dass ich die Teile, die Du mir geschickt hast mit meinen Milights nicht nutzen kann oder muss ich ein anderes Modul verwenden?
Zitat von: Gunther am 21 Oktober 2017, 21:52:40
Heißt das, dass ich die Teile, die Du mir geschickt hast mit meinen Milights nicht nutzen kann oder muss ich ein anderes Modul verwenden?
Eine gute Frage... Hardwaretechnisch sicher ginge das. Nur warum das Softwaretechnisch nicht klappt - da bin ich leider überfragt. :-[ MiLight scheint mir irgendwie ein zickiges System zu sein. >:(
Ich kann Dir leider nur anbieten, die Module gegen Erstattung des Kaufpreises zurück zu nehmen.
Anscheinend haben ja viele User hier Milight mit "Deiner" Hardware erfolgreich laufen. Müssen die Dinger nur nochmal neu geflashed werden?
Wer kann hier helfen?
Also die Bridges funktionieren mit Milight-Bridge und Milight-Device, das habe ich hier so (mit einer selbstgebauten Bridge) im Einsatz.
Soweit die Commandref Auskunft gibt, ist halt das Problem, dass das bessere FHEM-Modul (Wifilight) die Ports aus der Angabe des Modell abzuleiten scheint, bei Milight-Bridge kann man das direkt angeben. Mit etwas perl-Kenntnissen dürften sich auch "Klone" der normalen V3-Bridge (?, port 8899)erstellen lassen (im Wifilight-Modul), so dass man das dann auch zur Zusammenarbeit überreden könnte. Vielleicht kann Herrmanj da auch was reinbasteln, dass man den port mit angeben kann (als weiteren Parameter, z.B., der dann den Bridge-Standard überschreibt), vielleicht geht das sogar heute schon mit <IP:port>.
Da die Bridge deutlich besser im Netz hängt als die Kauf-Bridges, ist Milight-Bridge auch nicht mehr so das Problem...
Wifilight, zweimal ja:
- wenn man nichts angibt wird aus dem model ein default ermittelt: (v3: 8899 ...)
- kann man im define überschreiben/vorgeben: ..192.168.178.50:9999
Danke für die Infos!
grtz
cmdA
@Beta-User und herrmannj: das betraf jetzt nur die Frage von COmmanda, richtig?
Wer hat denn von hexenmeister Hardware zum Laufen bekommen und kann hier helfen?
Zitat von: Gunther am 22 Oktober 2017, 12:32:17
Wer hat denn von hexenmeister Hardware zum Laufen bekommen und kann hier helfen?
Ich habe nicht die Hexenmeister-Hardware, aber im Prinzip was baugleiches. Auf meiner Bridge läuft die V4 aus dem ersten Thread.
Was die Firmware angeht, sollte es aber auch mit der "anderen" firmware von hier https://github.com/sidoh/esp8266_milight_hub/releases (https://github.com/sidoh/esp8266_milight_hub/releases) gehen, siehe Thread hierzu hier (https://forum.fhem.de/index.php/topic,62114.0.html). Die hat den Vorteil, dass sich die Bridge auf den Code vorhandener Fernbedienungen einstellen läßt, die Anzahl der Ports im Prinzip unbegrenzt ist und die Wifi-Einstellungen nicht mit draufgeflasht werden müssen. Allerdings kann ich nicht aus eigener Erfahrung sagen, ob die Firmware wirklich funktioniert (sollte sie eigentlich und es kann sogar sein, dass die schon das neue Protokoll kann, das wäre ein echter Vorteil!).
@hermannj: Danke für die Info, das ist klasse!
Gruß, Beta-User
Mit welcher Software flasche ich?
Habe mich leider noch nicht damit beschäftigt. Gibts irgendwo eine Anleitung?
Das Projekt sieht sehr interessant aus! Ich will versuchen, in den nächsten Tagen Zeit zu finden, meine eingemotteten MiLIghts herauszukramen und damit mal versuchen.
Zum Flashen müsste so etwas in der Art vorhanden sein (auf 3,3V achten, 5V braten den ESP!): https://de.aliexpress.com/item/3-3V-to-TTL-UART-Module-Serial-Converter-Download-USB-drive-wire-brush-CP2102-STC-gift/32800462177.html
Dann ist Flashen ganz einfach, ich habe die BIN-Datei heruntergeladen und den Flasher-Tool beigepackt (alles im Zip im Anhang). Starten -> Port und BIN-Datei auswählen -> warten -> fertig. Probiert habe ich das jedoch nicht.
Edit: Ups, Anhang vergessen...
Oh, da muss ich mal schauen. Beta-User hatte mich im März mit einem Fundus ausgestattet. Leider hatte ich danach keine Zeit mich damit zu beschäftigen.
@Beta-User: weiß Du noch, ob da so ein 3,3-5 Volt Ding dabei war?
Edit: sieht nicht so aus. Ich habe mir so ein Teil mal geordert.
Zitat von: Gunther am 22 Oktober 2017, 19:04:10
@Beta-User: weiß Du noch, ob da so ein 3,3-5 Volt Ding dabei war?
Vermutlich. Sollte so ein längliches Teil sein, jede kurze Seite zwei PINs, ca. 3,5*0,7cm. In der Mitte ein länglicher IC, xxx1117 sollte draufstehen, eine Seite 3 Anschlüsse, oben länglich zum Wärme ableiten...
Ich scheitere gerade kläglich beim Versuch zu flashen. Ich stochere nach der Nadel im Heuhaufen, da ich zuwenig über die Hard- und Software weiß.
1. kann ich mit der von Dir, hexenmeister, angehängten exe nichts anfangen. Vermutlich installiert das Ding irgenwas (so wie ich lesen konnt, führt aber nichts mit Interface aus). In cmd auf Windows sagt das Ding "error no arguments given". Leider weiss ich nicht welche ich mitgeben soll und finde auch nichts im Netz.
Habe nun ESP8266Flasher.exe herunterleladen. Habe nun verschiedene COM-Ports (aus dem Gerätemanager) zusammen mit Deiner BIN probiert. Leider erfolglos. Steht auf Ready aber MACs bleiben leer.
Vermutlich scheitere ich schon an der Verkabelung zum UART Adapter.
Ich habe wie folgt verkabelt (finde im Netz aber andere Verkabelungen, weiss allerdings nicht, wie ich bei genau der mir vorliegenden Hardware vorgehen soll):
UART <--> auf die größere der beiden Platinen, wo hinten der ESP8266MOD draufhängt (nicht an der kleineren aufgelöteten Platine)
GND <--> GND
RXD <--> RX
TXD <--> TX
3V3 <--> 3.3V
Freue mich über Tipps:
1.) Welche Software unter Win7 64 die richtige ist
2.) Wie ich verkabeln muss
Sorry... für Euch ist das vermutlich gerade lustig mit mir ::)
Mit windo.* kann ich nicht wirklich helfen, aber vermutlich sollte hier die Beschreibung der Kommandos zu esptool.exe zu finden sein: https://github.com/espressif/esptool
Vertausche mal Rx+Tx auf einer der beiden Seiten (ist oft über Kreuz zu verkabeln).
Da sind zwei EXE drin. Starten muss Du den FlashESP8266.exe, die andere Datei wird intern benutzt (und sagt beim direkten Aufrufen eben "no arguments given").
Die FlashESP8266 bietet eine GUI. Entpacke einfach alles in ein Verzeichnis und starte sie. In dem Combobox kannst DU die Firmware auswählen, ist auch nur eine drin. Verfügbare Ports werden auch in einer Combobox angeboten.
Ich weiß leider gerade nicht, was Du für einen Adapter hast... Deine Verkabelung ist aber falsch. RX und TX werden über kreuz angeschlossen. Am besten schliesst Du nur GND<->GND, RX<->TX und TX<->RX an und anstatt 3,3V versorgst Du die Platine über USB.
Ah, danke, die 2. Exe ist mir untergegangen. RX-TX habe ich nun vertauscht und die Platine nur über USB versogt (an Rechner gesteckt).
Als Port habe ich 10 genommen (wird mir im Gerätemanager angezeigt für den UART Adapter).
Leider bekomme ich am Ende die Meldung "Flash failed".
Habt Ihr noch eine Idee?
Braucht das Ding noch einen Reset-Befehl (RST-PIN anschließen) oder muß ein PIN auf GND gezogen werden? Leider kenne ich die HW nicht, sondern orientiere mich an dem hier: http://www.esp8266.com/wiki/doku.php?id=loading_firmware...
@Hexenmeister: Hast du die firmware zwischenzeitlich mal getestet?
Hier sind auch wilde Verkabelungen zu sehen. Leider habe ich keine Ahnung, was ich tun kan ohne das Ding zu beschädigen.
https://wiki.fhem.de/wiki/ESP8266 (https://wiki.fhem.de/wiki/ESP8266)
Sofern das Ding aussieht wie es sollte (siehe hier: https://forum.fhem.de/index.php/topic,46304.msg380675.html#msg380675), sollte vermutlich auch die Anleitung aus dem Thread beachtet werden:
- FLASH-Taste drücken und halten, dann kurz RES drücken, FLASH loslassen.
Zitat von: Beta-User am 25 Oktober 2017, 13:28:06
Sofern das Ding aussieht wie es sollte (siehe hier: https://forum.fhem.de/index.php/topic,46304.msg380675.html#msg380675), sollte vermutlich auch die Anleitung aus dem Thread beachtet werden:
- FLASH-Taste drücken und halten, dann kurz RES drücken, FLASH loslassen.
Ganz genau ;)
Zitat von: Beta-User am 25 Oktober 2017, 12:59:28
@Hexenmeister: Hast du die firmware zwischenzeitlich mal getestet?
Leider noch nicht.
Zitat von: hexenmeister am 25 Oktober 2017, 13:34:09
Leider noch nicht.
Dann sind wir ja mal gespannt, was Gunther uns dann berichten kann...
Also, er sagt Flash complete! Danke! :)
Jetzt muss ich mal schauen, wie ich Zugriff bekomme, z. B. um WLAN einzustellen...
Ist die Size unten rechts die physische oder die, die aufgrund des Flashbereiches angezeigt wird?
als kleiner Tipp: man kann über die gleiche Verbindung die Konsolenmeldungen lesen. Evtl. kann das was nützliches stehen. Als Software eignet sich z.B. PuTTY dafür.
Leider findet mein Handy das WLAN des Adapters nicht. Oder bin ich auf dem Holzweg?
EDIT: Auch meine Fritzbox zeigt nix in der Umgebung an.
Muss ich noch irgendwas nach dem Flashen beachten?
Gleiche Verbindung heißt auf Windows was? Bei localhost anmelden?
Nach der Anleitung hier sollte ein neues WLAN zu finden sein:
https://github.com/sidoh/esp8266_milight_hub#get-ip-address
Evtl. braucht das einen Neustart "from scratch" => stomlos machen...
Dann die Codes der FB sniffen und die UDP-Ports dazu definieren (https://github.com/sidoh/esp8266_milight_hub#udp-gateways).
Wenn dann das paßt, wifilight-Devices definieren, dabei den Port mit angeben (siehe https://forum.fhem.de/index.php/topic,58742.msg702611.html#msg702611). Das erste definierte Device sollte dann den ersten Kanal nutzen usw.
Ich kenne zwar diese Software nicht, aber der Prinzip dürfte immmer der gleiche sein: Wenn ESP keine Anmeldedaten zum WLAN hat, macht es einen neuen AccesPoint auf. Namen können unterschiedlich sein, oft aber itgendwas mit 'ESP_xxx'. Wenn man sich damit verbindet, ist die GUI i.d.R. unter 192.168.4.1 erreichbar. Dort gibt man die WLAN-Daten an und startet das Ding neu. Dann sollte es auch in eigenem Netz auftauchen.
Update:
im GitHub des Autors steht:
ZitatConfigure WiFi
This project uses WiFiManager to avoid the need to hardcode AP credentials in the firmware.
When the ESP powers on, you should be able to see a network named "ESPXXXXX", with XXXXX being an identifier for your ESP. Connect to this AP and a window should pop up prompting you to enter WiFi credentials.
Genau das passiert leider nicht. Kein WLAN zu finden.
http://blog.christophermullins.com/2017/02/11/milight-wifi-gateway-emulator-on-an-esp8266/ (http://blog.christophermullins.com/2017/02/11/milight-wifi-gateway-emulator-on-an-esp8266/)
Hier beschreibt der Autor, dass man um sicherzugehen mit PlattformIO flashen soll. Macht es Sinn sich damit zu beschäftigen?
PlattformIO wird angeraten, wegen der Fehleranfälligkeit der cryptischen Commando-Zeilen-Tools.
In Deinem Fall wird das vermutlich nicht viel bringen. Schau mal, welche Meldungen werden beim Start/Reset über die Konsole ausgegeben.
Konsole auslesen ist eigentlich immer eine gute Idee (dazu am besten die Arduino-IDE nehmen, da den seriellen Monitor).
Ansonsten:
Soweit ich das im Kopf habe, sind die WLAN-Daten irgendwo abgespeichert, wo sie nicht zwingend gelöscht werden (aber vermutlich eben auch nicht sinnvoll gelesen werden können).
Kannst du mal versuchen, den flash wie im blog beschrieben komplett zu löschen?
Unter Linux:
esptool.py --port /dev/ttyUSB0 erase_flash
Unter Windo.* sollte das mit dem esptool auch gehen, bitte dazu die Hilfeseiten aufrufen, wie in dem wiki aus dem Beitrag weiter oben beschieben (die esptool.exe scheint eine für windo.* compilierte Variante zu sein, die Aufrufe dürften im Prinzip gleich sein, bis auf die OS-spezifischen links zum Dateisystem etc.).
Zitat von: hexenmeister am 25 Oktober 2017, 14:31:06
PlattformIO wird angeraten, wegen der Fehleranfälligkeit der cryptischen Commando-Zeilen-Tools.
In Deinem Fall wird das vermutlich nicht viel bringen. Schau mal, welche Meldungen werden beim Start/Reset über die Konsole ausgegeben.
Also Putty mit 115200 an Port10:
Da kommen nur 5-6 undefinierte Zeichen, wenn ich die Stromversorgung andocke.
Dann etwas "langsamer" versuchen.
Gesendet von meinem VKY-L09 mit Tapatalk
Danke, habe es auch mit 9600 versucht.
Lösche gerade nach der folgenden Methode:
http://www.pratikpanda.com/completely-format-erase-esp8266-flash-memory/ (http://www.pratikpanda.com/completely-format-erase-esp8266-flash-memory/)
woher weiß ich wieviel Speicher das Ding hat?
Zwischenstand:
Damit hat der immer noch so komische Meldungen beim Start gegeben, auch weil ich (falls er mehr als 2MB hat) die anderen Bereiche nicht sauber löschen konnte.
Habe dann Python installiert und über cmd
C:\Python27\Scripts>esptool.py -p COM3 -b 115200 erase_flash
den Flash gelöscht.
EDIT: Wenn ich mir den seriellen Datenverkehr anschauen kommen beim Start immer noch komische Zeichen...
Ich flashe gerade nochmal mit dem Tool aus dem ZIP von Hexenmeister.
So weiter im Gespräch mit mir selbst... :P
WIFI wird schonmal gefunden. Welcher Sicherheitsschlüssel, weiß ich gerade noch nicht...
Edit: In der Anleitung steht, dass ein "unsecured WiFi network" da sein muss. Wenn ich mich verbinden möchte, wird ein Sicherheitsschlüssel verlangt...
Habt Ihr eine Idee dazu?
Edit2: Sniffen hilft. Passwort ist: "milightHub"
Edit3:
Ich habe nun das Netzwerk auf mein WLAN eingestellt.
Jetzt gibt es komischerweise 2 neue Devices in meiner Fritzbox.
Beim Sniffen sagt er mir:
AutoConnect
Connecting as WiFi Client
Using last saved values, should be faster
Connection result:
3
IP Address:
192.168.0.128
Unter http://192.168.0.128 lässt sich leider keine Seite öffnen...
Edit4: Neu geflashed (Unter Info zeigt sich, dass das Ding 4MB hat, daher hat es vorher beim Flashen auch nicht geklappt, da ich nur 0-1 MB beschrieben habe)
Edit5:
Das ding wirft aus, solange ich noch nichts an den WLAN-Einstellungen geändert habe:
*WM: Connection result:
*WM: 0
*WM: SET AP STA
*WM:
*WM: Configuring access point...
*WM: ESP1253924
*WM: milightHub
*WM: AP IP address:
*WM: 192.168.4.1
*WM: HTTP server started
Edit6:
Ich bleibe an der Stelle hängen, an der ich das Ding in mein Netzwerk reinhänge. Kein Webinterface mehr da.
Der Datenverkehr sagt, dass sich das Ding ständig neu connected, denke ich:
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.0.152
⸮% ⸮9q⸮⸮*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.0.152
... usw.
Ein Connect mit der .152 geht nicht
Edit7: Über einen anderen Rechner habe ich nach längerem Warten eine Connection bekommen. Keine Ahnung ob die Verbindung stabil ist. Ich pinge mal.
So nun ist die Frage, wie ich an die Device Ids komme, die auf der Oberfläche des ESP8266 eingegeben werden müssen?
Wie bekomme ich Verkehr in den Sniffer?
Stehe gerade auf dem Schlauch.
Hi,
Schöner Monolog ;-)
Nur mal die Erklärung für die komischen Zeichen am Anfang. Das sind Meldungen vom Bootloader mit einer anderen Baurate (insbesondere steht da warum der ESP neu bootet oder auch Memory Dumps), danach übernimmt das Userprogramm (welches Du geflasht hast) mit einer geringeren Geschwindigkeit und diese Infos werden Dir dann leserlich angezeigt.
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
So, habe nun die Bridge über das MilightBridge Modul eingebunden.
Milightbridge_01
Status: ok
Dann habe ich meine RGBW-Steuerung für meine LED-Streifen definiert
defmod eg_ki_mi_LED MilightDevice RGBW Milightbridge_01 5
attr eg_ki_mi_LED IODev Milightbridge_01
attr eg_ki_mi_LED devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
attr eg_ki_mi_LED event-on-change-reading state,transitionInProgress
attr eg_ki_mi_LED lightSceneParamsToSave brightness
attr eg_ki_mi_LED restoreAtStart 1
attr eg_ki_mi_LED room 01_EG_Kino,G_Licht
attr eg_ki_mi_LED webCmd on:off:dim:ct:night
Dann habe ich mein altes notify rausgekramt:
define pairmilight_ki notify eg_ki_LEDStreifen:on sleep 0.2;; set eg_ki_mi_LED pair
eg_ki_LEDStreifen ist mein Homematic-Switch, der vor der Milightsteuerung hängt.
Homematic an.
geprüft:
In Kanal 5 von Milightbridge_01 steht eg_ki_mi_LED
Sieht super aus!
notify ausgeschaltet.
Test: Leider keine Reaktion.
Muss ich nun zuerst in der Oberfläche der Bridge was machen? Falls ja: Wie? ???
Wenn ich die Anleitung im Blogbeitrag richtig lese,
- erstelle ich einen Gateway und speichere diesen
- vergebe ich selbst eine ID (z. B. 0x0000) und
- mache die Lampe an und drücke dann sofort pair.
Leider tut sich nichts.
Komisch ist ja auch, dass beim mitsniffen IDs erscheinen. Daraus lese ich, dass die fix in den Geräten sind.
Irgendwie bin ich von meinem Handeln noch nicht überzeugt... :o
Das Problem könnte daran liegen, dass die Bridge ständig AutoConnect macht und anscheinend nicht stabil da ist. Dann wird Pairen in der Oberfläche schwierig.
Nur um sicherzugehen:
@hexenmeister:
Ist die Firmware in Deinem Zip für meine Hardware die richtige?
Zitat von: Gunther am 25 Oktober 2017, 22:39:19
Nur um sicherzugehen:
@hexenmeister:
Ist die Firmware in Deinem Zip für meine Hardware die richtige?
Laut der Info, wie ich die Beschreibung verstanden habe (https://github.com/sidoh/esp8266_milight_hub/releases), sollte es passen. Man könnte noch auch die Version für D1Mini probieren (da ist auch ESP12 drauf) oder eben ein vorherige Version (z.B. 1.6.0-dev7).
probiert habe ich die Version 1.5.
Leider connected der ständig neu.
Daher ist keine Konfiguration möglich.
Habe auch schon mit einem anderen Flashtool und 9600 Baud auf 4MB geflashed.
Leider ohne Erfolg.
Freue mich, wenn Du auch mal testen kannst.
Zitat von: Gunther am 25 Oktober 2017, 23:48:22
Freue mich, wenn Du auch mal testen kannst.
Heute nicht mehr, vlt. schaffe ich es morgen.
Hallo zusammen.
Habe da mit meinem selbstgebauten Gateway nach Mysensors auch so meine Probleme.
Egal ob der Nrf24l01+ mit oder oder ohne pa ist. Bin und wieder kann ich die Fernbedienung sniffen.
Von mir meinem Gateway Max 1m von den Lampen entfernt.
Über die fb klappt alles wunderbar. Nur frag mit dem gateway nicht. Habe die ID Von der fb genommen und ins Gateway eingetragen.
Aber schalten klappt nicht.
Habe von sidoh die 1.5.0 auf dem Gateway.
Habe auch nen Kondensator an plus und minus von Nrf gelötet.
Aber nix klappt.
Hat hier jemand noch eine Idee.?
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
Steht Dein Gateway konstant im WLAN. Wie sehen die seriellen Meldungen aus?
Habe jetzt die Software geflasht... Anscheinend das gleiche Problem - sniffen geht, beim senden - stürzt ESP ab (sieht man gut in der console). Gute Frage warum. Ich will morgen mit einem Aufbau aus Wemos und Drähten versuchen, mal sehen, ob sich etwas an der Instabilität ändert, auch wenn ich gerade nicht wüsste warum das sein sollte >:(
Danke fürs Testen! Bin gespannt!
Ich beobachte dieses Thema auch schon eine Weile. Freut mich, wenn es weiter geht.
Meine Hardware ist noch nicht da, daher kann ich gerade nicht viel beitragen, wollte aber trotzdem ein Danke für eure Mühe da lassen.
Gesendet von meinem Pixel mit Tapatalk
Habe jetzt aus einem Wemos, NRF-Modul und Drähten die notwendige Hardware zusammengebaut und MilightHub-Firmware drauf gespielt. Leider das gleiche Problem - Sniffen geht, bei jedem Versuch etwas zu senden stürzt ESP ab. >:(
Verdammt schade, wäre sonst sehr coole Software. Ich versuche noch mal mit einem NodeMCU-Modul, wi der Author auf seiner Seite beschreibt (http://blog.christophermullins.com/2017/02/11/milight-wifi-gateway-emulator-on-an-esp8266/)...
So, ich hab's! 8)
Der Author verweist auf Seiner Seite auf die Seite von MySensors bezüglich der Verbindung ESP<->NRF. Danach ist auch mein Modul verdrahtet. Jetzt habe ich seine Seite _aufmerksam_ gelesen. Dort beschreibt er die Verbindung leicht anders. Für den CE-Signal verwendet es nicht D2 (wie bei MySensors), sondern D0!
Umgesteckt - und siehe da, es funktioniert! Es geht aber auch noch besser - man kann die Pins auch in der WebUI definieren. Für CE muss man '4' anstatt '16' angeben - und schon geht es auch mit meinem Modul :)
Edit: Wie es aussieht, werden die Werte auch dauerhaft gespeichert :)
Super!
Nur: Wie kommst Du ins Web UI.
Das scheint ja eher Zufall zu sein...
Keine Ahnung. :o Funktioniert bei mir absolut stabil.
Edit: habe die Version aus meiner ZIP verwendet.
D.h. Du stellst das WLAN über die 192.168.4.1 ein und verbindest Dich dann zu der per DHCP vergebenen IP?
Das ist ja mein Problem, dass ich da nur alle halbe Stunde reinkomme.
Ich teste mal das 2. Modul (habe den Karton heute gesucht und gefunden ;) )
Zitat von: hexenmeister am 28 Oktober 2017, 22:23:20
So, ich hab's! 8)
Der Author verweist auf Seiner Seite auf die Seite von MySensors bezüglich der Verbindung ESP<->NRF. Danach ist auch mein Modul verdrahtet. Jetzt habe ich seine Seite _aufmerksam_ gelesen. Dort beschreibt er die Verbindung leicht anders. Für den CE-Signal verwendet es nicht D2 (wie bei MySensors), sondern D0!
Umgesteckt - und siehe da, es funktioniert! Es geht aber auch noch besser - man kann die Pins auch in der WebUI definieren. Für CE muss man '4' anstatt '16' angeben - und schon geht es auch mit meinem Modul :)
Edit: Wie es aussieht, werden die Werte auch dauerhaft gespeichert :)
Werde das mal mit dem cs ob ausprobieren.
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
Leider genau dasselbe wie mit dem ersten Modul.
1. Webebene klappt. Zweite leider nicht mehr.
Serielles Sniffen sagt
⸮! ⸮=r⸮⸮*WM:
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.0.167
⸮! ⸮=r⸮⸮*WM:
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.0.167⸮! ⸮=r⸮⸮*WM:
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.0.167⸮! ⸮=r⸮⸮*WM:
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.0.167
...
...
usw.
Ich bin in meinem WLAN komme aber nicht auf die 192.168.0.167.
@hexenmeister: sieht das bei Dir anders aus? Hattest Du nicht auch diese reconnects?
Kann das an meiner Hardware oder sogar an meinem Dongle zum Flashen liegen? Oder an meinen USB Ports, oder... *grrr* ;)
Oder kann es an meiner WLAN SSID liegen (hat Leerstellen)? Wird aber im Autoscan gefunden.
Zitat von: Gunther am 28 Oktober 2017, 23:16:22
Oder kann es an meiner WLAN SSID liegen (hat Leerstellen)? Wird aber im Autoscan gefunden.
Das ist es. Ich habe Leerstellen und "," in der SSID. Das sieht der Autor vermutlich nicht vor.
Mist, dann muss ich die ändern.
Aber super, dass es läuft! Beschäftige mich dann mal mit der Oberfläche.
Magst Du mal erklären, wie Du in der Software vorgehst?
Ich habe CE auf 4 geändert, gespeichert und neu gestartet. Bleibt auch gespeichert.
Nun bekomme ich das Pairen nicht hin.
Ich schalte meinen Milightcontroller an und drücke in der Oberfläche Pair.
Kann ich mir nun diverse Gateways anlegen, die dann meine alten Bridges ersetzen?
Also z. B. unter Bridge 0x1 --> save
dann oben unter Device ID die 0x1 eintragen, auf Group 1 klicken, Strom an, pair?
Hi Gunther,
schön, das wir einen Schritt weiter sind :)
Mit dem Pairen habe ich eigentlich gar nicht versucht. Meine Lampen waren bereits mit der vorhandenen Fernbedingung gepairt, ich habe dann einfach die ID der FB gesnifft und diese auch zum Testen verwendet. Klappt das bei Dir vlt. auch auf diese Weise?
Ich habe auf der FB testweise Taste 1 mit der Lampe gepaired.
Beim Sniffen auf allen 4 Tasten wird die gleiche ID angezeigt. Habe ich jetzt oben mal eingetragen unter Device ID mit einem führenden "0x".
Jetzt sollte ich doch eigentlich auf group 1 gehen und steuern können. Oder verstehe ich etwas falsch? Geht das bei Dir?
Hast Du schon in FHEM eingebunden?
Zitat von: hexenmeister am 28 Oktober 2017, 22:23:20
So, ich hab's! 8)
Der Author verweist auf Seiner Seite auf die Seite von MySensors bezüglich der Verbindung ESP<->NRF. Danach ist auch mein Modul verdrahtet. Jetzt habe ich seine Seite _aufmerksam_ gelesen. Dort beschreibt er die Verbindung leicht anders. Für den CE-Signal verwendet es nicht D2 (wie bei MySensors), sondern D0!
Umgesteckt - und siehe da, es funktioniert! Es geht aber auch noch besser - man kann die Pins auch in der WebUI definieren. Für CE muss man '4' anstatt '16' angeben - und schon geht es auch mit meinem Modul :)
Edit: Wie es aussieht, werden die Werte auch dauerhaft gespeichert :)
Hast Du das mit dem Modulaufbau wie ich es hier liegen habe mit dem Eintrag 4 bei CE getestet? Das Feld bleibt bei mir farbig. Normal?
Ich habe mit dem CE-Pin 4 mit dem gleichen Modul versucht, wie Du ihn hast.
Vorhgenhensweise auch, wie Du beschrieben hast. Die Lampen lassen sich steuern. Was meinst Du mit "Feld bleibt farbig"?
In FHEM habe ich nicht versucht einzubinden.
Das Feld ist gelb.
Muss ich meine RGBW Steuerung erst resetten oder unpaired?
Ich habe noch die älteren Steuerung-Versionen. Mir ist noch nicht ganz klar wie für die Software ist.
Zitat von: sash.sc am 28 Oktober 2017, 23:03:52
Werde das mal mit dem cs ob ausprobieren.
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
Habe heute morgen den Pin in der fliegenden Verdrahtung umgesteckt.
Habe dann auch noch die neuen Version 1.6.0 dev9 geflasht.
Dann auf dem WEBIF des Controllers eingelogt, meine gesniffte ID genommen, und die Lampen lassen sich ohne Probleme steuern !!!
Gruß und Danke
Sascha
P.S.: manchmal liegt der Teufel im Detail ;-)
Welche Controllerversion hast Du?
Habe diese aktuelle Version auf meinen WEMOS D1 mini geflasht.
https://github.com/sidoh/esp8266_milight_hub/releases (https://github.com/sidoh/esp8266_milight_hub/releases)
Wie gesagt, jetzt lässt sich über das WEBIF die Lampen steuern. Muss jetzt nur noch das ganze in FHEM einbetten.
Weiss da aber noch nicht welches Modul ich da bevorzugt nehmen soll !
Gruß
Sascha
Ich meinte Milight Controller. Oder setzt Du nur Lampen ein?
Ich möchte meine LED Streifen steuern.
Nein, ich habe keinen Controller.
Der Controller ist bei mir der wemos mit dem nrf24l01 Modul.
Und 2 Lampen habe ich.
Eigentlich sollte sich der LED-Controller nicht anders verhalten wie eine Bulb (bzw. eine Gruppe davon).
Auf welchen Kanal der FB hast du ihn gepairt und welches FHEM Modul nutzt du?
Bei Wifilight muß ggf. ein oder mehrere "Leer"-Device(s) vorher definiert sein, wenn nicht Kanal 1 auf der FB benutzt wird. Bei Milight war das irgendwie ähnlich.
Gruß, Beta-User
Ich habe den Kanal 1 auf der FB getestet. Möchte aber generell auch pairen ohne Fernbedienung.
In FHEM bin ich noch gar nicht.
Also:
Der Controller läßt sich von der FB ansteuern?
Dann würde ich erst mal die ID der FB nutzen und darauf den ESP konfigurieren. Dann sollte sich der Controller auch vom ESP aus genau so bedienen lassen wir von der FB. Dann weißt du, ob die HW ordentlich funktioniert.
Die Leuchtmittel können nicht unterscheiden, von woher der Steuerungsbefehl kommt, sie werden reagieren, solange die ID des Senders authorisiert ist ("gepairt").
Du kannst dann eine andere (gültige) ID einstellen und den Controller darauf zusätzlich anlernen, dazu ist kein spezieller Pairing-Befehl erforderlich, sondern nur irgendein gültiger Schaltbefehl vom ESP kurz nach dem Einschalten der 230V für das Leuchtmittel, ich verwende typischerweise reinweis, volle Helligheit. Damit kann man auch ein unpair durchführen ;) .
Soweit sollte es eigentlich klappen...
Ich bräuchte da nochmal eure Hilfe.
Da ja jetzt die Ansteuerung über den Controller direkt klappt, wollte ich das ganze in FHEM mit dem Wifilight Modul einbauen.
Hier das List
Internals:
CFGFN
CONNECTION bridge-V3
DEF RGBW2 bridge-V3:192.168.2.110
IP 192.168.2.110
LEDTYPE RGBW2
NAME wz.ecke
NR 73208
NTFY_ORDER 50-wz.ecke
PORT 8899
PROTO 0
SLOT 5
STATE on
TYPE WifiLight
READINGS:
2017-10-29 14:11:49 RGB CCCCCC
2017-10-29 14:11:49 brightness 80
2017-10-29 14:11:49 hue 210
2017-10-29 14:11:49 saturation 0
2017-10-29 14:11:49 state on
helper:
COMMANDSET on off dim dimup dimdown HSV RGB sync pair unpair
colorLevel 0
colorValue -1
llLock 0
mode 2
targetHue 210
targetSat 17
targetTime 1509282709.74337
targetVal 80
whiteLevel 20
COLORMAP:
168
167
167
166
166
165
165
164
163
163
162
162
161
161
160
159
159
158
158
157
157
156
156
155
154
154
153
153
152
152
151
150
150
149
149
148
148
147
146
146
145
145
144
144
143
142
142
141
141
140
140
139
139
138
137
137
136
136
135
135
134
133
132
132
131
130
129
129
128
127
126
126
125
124
123
122
122
121
120
119
119
118
117
116
116
115
114
113
113
112
111
110
109
109
108
107
106
106
105
104
103
103
102
101
100
99
99
98
97
96
96
95
94
93
93
92
91
90
90
89
88
87
87
86
86
85
85
84
84
83
83
82
82
81
81
80
79
79
78
78
77
77
76
76
75
75
74
74
73
73
72
71
71
70
70
69
69
68
68
67
67
66
66
65
65
64
63
63
62
62
61
61
60
60
59
59
58
58
57
57
56
55
54
54
53
52
51
50
50
49
48
47
46
46
45
44
43
42
42
41
40
39
38
38
37
36
35
34
34
33
32
31
30
30
29
28
27
26
26
25
24
23
22
22
21
20
19
18
18
17
16
15
14
14
13
12
11
10
10
9
9
8
7
6
5
4
3
2
2
1
0
254
253
252
251
250
249
248
247
246
245
244
243
243
242
241
240
239
238
237
236
235
234
233
232
231
230
229
229
228
227
226
225
224
223
222
221
220
219
218
217
216
215
215
214
213
212
211
210
209
208
207
207
206
205
205
204
203
203
202
201
201
200
199
199
198
197
197
196
195
195
194
193
193
192
191
191
190
189
189
188
187
187
186
185
185
184
183
183
182
181
181
180
179
179
178
177
177
176
175
175
174
173
173
172
171
171
170
169
169
GAMMAMAP:
0
0.182084917038383
0.470591230357907
0.820096073367633
1.21622432924022
1.65107624587364
2.11950570346478
2.61783651126499
3.14328343499055
3.69364788963403
4.26714092851856
4.86227250061747
5.47777824197178
6.112568939676
6.76569440648595
7.43631690144944
8.12369109476553
8.82714865073238
9.54608615125084
10.2799554881179
11.0282561143647
11.7905287188301
12.566350006457
13.3553283490082
14.1571001291331
14.971326642687
15.7976914549342
16.6358981290745
17.4856682626968
18.3467397808198
19.2188654442296
20.1018115396355
20.9953567242883
21.899291002556
22.8134148158172
23.7375382301393
24.6714802087245
25.615067958155
26.5681363391464
27.5305273339062
28.5020895633382
29.4826778482926
30.4721528098611
31.470380504392
32.4772320894657
33.4925835175601
34.5163152545402
35.5483120204638
36.5884625504948
37.6366593739748
38.6927986099313
39.7567797774927
40.8285056198529
41.9078819405719
42.994817451133
44.0892236287856
45.1910145838062
46.3001069353943
47.4164196955005
48.5398741599513
49.6703938062953
50.8079041978503
51.9523328934805
53.1036093626722
54.2616649055192
55.4264325772608
56.5978471170475
57.7758448806357
58.9603637767409
60.1513432067978
61.3487240079
62.5524483987055
63.7624599281173
64.9787034265577
66.2011249596724
67.429671784312
68.6642923066494
69.9049360423029
71.1515535783445
72.4040965370806
73.6625175415008
74.9267701822992
76.1968089863762
77.4725893867394
78.7540676937228
80.0412010674534
81.3339474914964
82.6322657476148
83.9361153915856
85.2454567300145
86.5602507980997
87.8804593382937
89.2060447798182
90.5369702189896
91.8731994003132
93.21469669831
94.5614271000383
95.9133561882787
97.2704501253487
98.6326756375187
100
hlCmdQueue:
llCmdQueue:
Wenn ich jetzt über das Wifilight device einen Befehl absetzen möchte, klappt es natürlich nicht.
Wie gesagt, manuelles schalten über das WEBIF des Coontrollers klappt.
Muss in der DEF noch ein Port oder sowas angegeben werden ?
Im Controller ist die gesnuffte ID eingetragen.
Gruß
Sascha
Ohne den Code analysiert zu haben, sieht es für mich so aus, dass diese Firmware eigene API hat, die nicht micht mit dem alten Gateway kompatibel ist. Somit müsste WifiLight-Modul vermuttlich entsprechend erweitert werden. Frage am besten bei dem Entwickler des Moduls nach (am besten in einem neuen Thread).
Ich Habe den ESP mit der FW von Sidoh (1.6.0 dev9) am laufen. Wie gesagt, über WEBIF vom Controller lässt sich die Lampe steuern.
Die Lampen die Ich habe sind die FUT014 (RGBW E14).
Habe in der Controller WEBIF auch den discovery Port von 48899 auf 8899 gestellt.
Tut sich aber noch nix.
Der Traffic lässt sich ja auch sniffen
Gruß
Sascha
Zitat von: sash.sc am 29 Oktober 2017, 14:14:54
Ich bräuchte da nochmal eure Hilfe.
Da ja jetzt die Ansteuerung über den Controller direkt klappt, wollte ich das ganze in FHEM mit dem Wifilight Modul einbauen.
Wenn ich jetzt über das Wifilight device einen Befehl absetzen möchte, klappt es natürlich nicht.
Wie gesagt, manuelles schalten über das WEBIF des Coontrollers klappt.
Muss in der DEF noch ein Port oder sowas angegeben werden ?
Im Controller ist die gesnuffte ID eingetragen.
Gruß
Sascha
Ohne es probiert zu haben vielleicht ein Anstoß für Dich.
(1. Kann ich nicht testen und 2. kenne ich wifilight nicht)
Kannst Du nicht in der Oberfläche ein Gateway mit Port anlegen und darauf Deine Kanäle mappen.
Dann hast Du ip:Port für die bisherigen WiFi Bridges.
Irgendwo in den Posts vorher stand, dass Du in Wifilight einfach den Port in der Definition mit angeben kannst.
Dann für jedes Gateway ein eigenes wifilight Device anlegen.
Habe jezt in GitHub gelesen uns sehe es so wie Gunther. Lege ein Gateway an.
ZitatUDP Gateways
You can add an arbitrary number of UDP gateways through the REST API or through the web UI. Each gateway server listens on a port and responds to the standard set of commands supported by the Milight protocol. This should allow you to use one of these with standard Milight integrations (SmartThings, Home Assistant, OpenHAB, etc.).
You can select between versions 5 and 6 of the UDP protocol (documented here). Version 6 has support for the newer RGB+CCT bulbs and also includes response packets, which can theoretically improve reliability. Version 5 has much smaller packets and is probably lower latency.
Also anstatt über das Modul WIFILIGHT dann über MILIGHTBRIDGE und MILIGHTDEVICE ?
Sollten mWn beide funktionieren.
Beide funktionieren aber nicht ! :(
gruß
Sascha
Nutzt du den ersten Kanal von der FB? Sonst mußt du erst eine entsprechende Anzahl von "Leer-Bulbs" anlegen (für den 3. Kanal zwei vorrangige). Bei Milight_Device ist bei mir dann noch die Slot-Nr. mit in der DEF.
Die Leuchtmitteltype stimmt (sonst wird uU der falsche Kanal des GW angesprochen)?
Ansonsten hat Hermannj bestätigt, dass ip:port auch bei Wifilight funktioniert. Und dass sidoh die UDP-Variante in V0.9 wieder ausgebaut hat, bezweifle ich...
Nicht den discovery Port ändern, sondern ein Gateway anlegen.
geh im WebIF auf "add server"
dort z. B. 0x1 und port 8800 und auf save
dann Deine Geräte da reinpacken/pairen (kann ich leider nicht prüfen, da das bei mir nicht klappt)
dann in FHEM 192.168.x.x:8800
(natürlich IP ersetzen)
Ich frage mich langsam, ob das Problem bei Dir, Gunther mit dem LED-Streifen-Controller zusammenhängt... Bei allen andere scheint es mit Lampen zu funktionieren. Vlt. braucht dieser einen anderen Modus, hast Du schon die verfügbaren Modi (umschaltbar ober rechts) durchprobiert?
Was meinst Du mit "Modi (umschaltbar ober rechts)"?
falls Du die Weboberfläche (5, 6 bzw. RGBW,...) meinst: ja
Ober in der WebUI steht unter "Mode": RGBW, CCT, RGB+CCT, RGBl, FUT089
Ja habe alles ausprobiert.
Was mir aufgefallen ist: Die Reichweite des Moduls ist sehr begrenzt. Wenn ich die Fernbedienung 3 Meter entfernt habe, kommt beim Sniffen nichts mehr an.
Daher habe ich eben das Modul mal direkt neben die Milightsteuerung platziert. Leider ohne Erfolg.
Ich habe auch noch ww LED controller. Die Oberfläche sieht nicht so aus als ob man die steuern kann.
Langsam fällt mir hier nichts mehr ein. Warte noch auf eine Antwort vom Autor.
Habe heute nochmal eine meiner WiFi-Bridges mit dem Handy gekoppelt und mitgesnifft. Die Adresse habe ich verwendet.Klappt leider nicht. (Ich hatte meine Fernbedienung als "Fehlerquelle" vermutet)
EDIT: Nachmal an einem anderen RGBW Controller getestet. Leider dasselbe.
Habe mir nun zum Test eine Huebridge und ein Vorschaltgerät bestellt (http://www.hiergibtshilfe.de/2015/10/philips-hue-mit-beliebigen-led-stripes-erweitern/#.Wfc4dRPWzMV).
Dann muss ich mich von der schönen Funktion des "Letzte-Stand-Speicherns" verabschieden und das in FHEM mit anderen Mitteln lösen.
Danke für Euren tollen Support hier!
@Hexenmeister: Noch ne Dummyfrage: Kann ich mit der Hardware von Dir ohne Umbau auch etwas anderes anfangen, wenn ja: unter welchen Begriffen suche ich im Netz danach! ::)
Achja: Die Dinger scheinen ja bei Euch zu funktionieren. Falls hier noch weitere Leute mit Milights rumschwirren, die Interesse an meinen beiden Controllern haben: Hebt die Finger. Ich gebe sie gerne weiter.
Zitat von: Gunther am 30 Oktober 2017, 14:50:55
Noch ne Dummyfrage: Kann ich mit der Hardware von Dir ohne Umbau auch etwas anderes anfangen, wenn ja: unter welchen Begriffen suche ich im Netz danach! ::)
Die Geräte waren ursprünglich als MySensors-WLAN-Gateway konzipiert (https://www.mysensors.org/build/esp8266_gateway). Also solche laufen sie auch bei mir. Die Idee mit Milight kan aus dem Thread hier. Ich wollte sogar Milights bei mir einsetzen. Habe mir mehrere Lampen bsorgt, bin jedoch letztendlich davon abgekommen. Nicht wegen dem Gateway, sondern weil ich die Lampen nicht immer am Netz lassen möchten sie aber beim einschalten mit dem erstbesten Pairen. Bei mehreren Zimmern entstehen so immer wieder falsche Verbindungen. >:(
Danke, ich werde die Dinger mal auf Halde legen und zu gegebener Zeit wieder rauskramen. :)
Hallo zusammen !
Habe es jetzt mit FHEM und dem Modul WIFILIGHT und der Firmware von Sido aus den vorhergehenden Post´s am laufen bekommen.
Mit eine Server imm WEBIF (Tip von Gunther) war schon nicht schlecht. Das wichtigste dabei ist aber nicht die Adresse 0x1 zu nehmen, sondern die gesniffte ID, insofern es möglich war zu sniffen.
Also:
1. Vorraussetzung ist das die FW von Sidoh geflasht ist und erreichbar ist.
2. Wenn man keine FB zum sniffen hat, dann eine ID ausdenken (z.B. 0x2000), dann Lampen pairen
3. zu beachten ist dann noch die CS/CN Leitung umstecken oder den PIN in die WEBIF eintragen. (tip von Hexenmeister zuvor)
4. Dann den Server in der WEBIF eintragen. Ganz wichtig, im Server die ID des devices eintragen, welches man schalten will, mit PORT angabe.
5. Das ganze speichern.
6. Dann mit dem Modul WIFLIGHT und der PortAngabe hinter IP ein Device einrichten, oder das Ganze über das Milight Modul !!!!
Hoffe ein wenig weiter geholfen zu haben !!!
Gruß
Sascha
Schön, dass es geklappt hat!
Ich habe heute mein Dresden Elektronik Vorschaltgerät und die HUE Bridge bekommen und testweise eingebunden. Bin begeistert: Easy Einbindung und RGB+WW gleichzeitig. Ganz anderes Farbverhalten 8)
So....bei mir läuft's nun auch.
Dank Saschas Vorabeit, war es relativ fix erledigt.
Habe hier 5x GU10 5W in meiner Stube an der Decke hängen.
Auf eine Wemos D1 mini Klon die aktuelle FW (RC1) von sidoh geflasht. https://github.com/sidoh/esp8266_milight_hub/releases/tag/1.6.0-rc1 (https://github.com/sidoh/esp8266_milight_hub/releases/tag/1.6.0-rc1)
Ich musste zuvor den Wemos leeren (esptool.py -p COM6 -b 115200 erase_flash), da sonst irgendwie keine Konfiguration möglich war.
Das Shield das ich benutze verbindet CE des NRF24L01+ mit D2 des Wemos. Also im Webinterface den Pin kurzerhand auf 4 geändert und siehe da....Sniffen der Fernbedienung klappt
Die ausgelesene ID habe ich nun wie im Printscreen von Sascha als Gateway eingetragen (mit 0x davor: 0x6814) UDP-Port 8800.
In FHEM folgendes define:
define wz.licht.decke WifiLight RGBW2 bridge-V3:172.16.0.65:8800
attr wz.licht.decke room MiLight
attr wz.licht.decke webCmd RGB:on:off
attr wz.licht.decke widgetOverride RGB:colorpicker,RGB
Soweit klappt das prima.
Leider habe ich keine Ahnung von MQTT.
Das wäre jetzt noch das Sahnehäubchen, um Ferndedienung und FHEM zu synchronisieren.
Hallo,
kann mir jemand weiterhelfen. Ich möchte meine Milight Bridge ersetzen, weil ich gerne mehr als 8 Zonen schalten will.
Im Moment laufen bei mir 2 gekaufte Bridge und ich habe gelesen das die neue Bridge (IBOX) nicht mehr mit FHEM funktionieren.
Irgendwie blicke ich nicht alles was Ihr da genau macht. Was benötige ich genau für Komponenten und wie muss ich es verbinden und In betriebnehmen. Eine kleine zusammenfassende Anleitung wäre super. Ich habe keine Fernbedienung.
Vielen Dank :)
Lucca
Es braucht:
- Einen ESP8266, (am besten einen Wemos oder eine NodeMCU)
- Ein (funtionierendes) nRF24L+-Modul (gibt leider viele fakes)
- einen Kondensator (leider ist die Größe vom konkret verwendeten nRF abhängig, die eine große Serienstreuung aufweisen)
oder
- Ein GW von Hexenmeister, auf dem diese Komponenten bereits verbaut sind
Den Sketch von sidoh (alternativ einer der beiden aus dem ersten Beitrag, diese Anleitung aber für die sidoh-Variante).
An der Web-Oberfläche muß man zum einen einen PIN anpassen, wenn man die Hexenmeister-HW verwendet oder nach MySensors-Vorgabe verkabelt hat.
Dann kann man eigene FB-Codes vergeben (oder die der vorhandenen Bridges sniffen, die sind insoweit auch nichts anderes als eine FB), dazu einen Port festlegen und kann dann jeden der Ports als wifilight-Gerät (oder Milight-Bridge) verwenden.
That's it ;) .
Hallo Beta-User,
Vielen Dank, das hört sich ja schon mal ganz gut an. Werde mir das GW von Hexenmeister besorgen und das mal probieren.
Gruß Lucca :)
Du solltest hexenmeister noch mitteilen, dass er ihn nicht als MySensors-GW flashen soll (bzw. gleich mit der sidoh-Firmware), sonst kann es Probleme mit der WLAN-Verbindung geben (muß dann erst wieder komplett gelöscht werden, siehe einige Beiträge weiter oben).
Du kannst das relativ simpel auch selbst aufbauen:
http://blog.christophermullins.com/2017/02/11/milight-wifi-gateway-emulator-on-an-esp8266/
Kurzer Nachtrag zu meinem anderen Post:
Ich empfehle die Verwendung von MilightDevice und MilightBridge statt des WifiLight-Moduls, wenn
man mehrere Zonen steuern möchte. (https://wiki.fhem.de/wiki/MilightDevice)
@lucca111
Du versuchst da ein GW zu bekommen, das zwar die Platine verwendet, aber fake-nRF's ("blob-Version"). Das ist ausdrücklich nicht zu empfehlen und es ist auch nicht hexenmeister, der so einen Schrott anbietet!
hexenmeister hat dazu einen eigenen Thread.
Zu bestätigen ist, dass der Bau eigener HW einfach ist (wenn man die Bauteile hat), ich habe wg. der besseren Reichweite einen nRF mit pa+lna ohne Platine verwendet ;) .
@FLOK
Mehrere Zonen sollten auch mit Wifilight gehen (lt. commandref: der erste Kanal ist das erste auf dem jeweiligen Port definierte Wifilight usw.), m.E. kann man Milight-Bridge/Device nicht mehr guten Gewissens empfehlen, da ist die Entwicklung seit langem verwaist und das Modul blocking ausgelegt, grrrr >:( ).
Mal von den konkret zu verwendenen Modulen ab: die Milight-Technik an sich ist keine, deren Ausbau ich empfehlen würde (siehe die Diskussion zu Beginn dieses Threads) ::)
ZitatMehrere Zonen sollten auch mit Wifilight gehen (lt. commandref: der erste Kanal ist das erste auf dem jeweiligen Port definierte Wifilight usw.), m.E. kann man Milight-Bridge/Device nicht mehr guten Gewissens empfehlen, da ist die Entwicklung seit langem verwaist und das Modul blocking ausgelegt, grrrr >:( ).
Okay, schaue ich mir gerne nochmal an.
Habe noch 2 fertige abzuheben
Zitat von: FLOK am 07 November 2017, 11:21:10
Kurzer Nachtrag zu meinem anderen Post:
Ich empfehle die Verwendung von MilightDevice und MilightBridge statt des WifiLight-Moduls, wenn
man mehrere Zonen steuern möchte. (https://wiki.fhem.de/wiki/MilightDevice)
ja, kannst Du das bitte erläutern ? (Keine Fangfrage) Mit Wifilight gehen mehrere Zonen (1+4+4) pro bridge und mehrere bridge pro fhem. Wenn es da Probleme im Zusammenhang mit den gateways gibt dann weiß ich noch nichts davon ...
Ich denke das ist einfach meiner Unwissenheit und Unerfahrenheit geschuldet.
Nachdem Beta-User geantwortet hat, habe ich nochmal einen Blick in die Commandref geworfen:
ZitatDie LED wird den maximal 4 verfügbaren Gruppen pro bridge in der Reihenfolge der Definition zugeordnet:
Ist das so zu verstehen: (?)
define Kanal1 WifiLight RGBW2 bridge-V3:172.16.0.65:8800
define Kanal2 WifiLight RGBW2 bridge-V3:172.16.0.65:8800
define Kanal3 WifiLight RGBW2 bridge-V3:172.16.0.65:8800
define Kanal4 WifiLight RGBW2 bridge-V3:172.16.0.65:8800
Falls nicht, dann blick ich es immernoch nicht :(
Meine Fernbedienung sendet ja nur 1 ID (0x6814) und diese wird im Modul auf Port 8800 als Gateway eingetragen.
D.h. alle 4 Kanäle müssen auch darüber angesprochen werden können...
@FLOK
Das solltest du mit einer Kaufbridge ausprobieren können; wenn es da geht, klappt es auch mit der sidoh-bridge und entsprechenden Ports.
Aus gegebenem Anlaß:
Ich hatte auch Mühe, diese einfache Wahrheit aus der (deutschen) commandref rauszulesen und war bislang auch zu faul, die Milight_Bridge/Device-Konfigruation durch Wifilight abzulösen. Als ich mich damals der Thematik genähert habe, habe ich dann mehr oder weniger zufällig dann das "falsche" Modul ausgewählt, einfach, weil es passender klang und mir der 2-stufige Aufbau einleuchtend erschien.
Zwischenzeitlich muß man es m.E. so deutlich sagen: Milight_Bridge sollte man nicht mehr einsetzen. Zwar sind solche Empfehlungen innerhalb der FHEM-community bislang eher selten, aber in dem Fall wäre mein Vorschlag dazu folgender:
1. Hinweis in's wiki zu den Milight-Artikeln, dass man besser Wifilight nutzen sollte
2. Commandref ggf. etwas aufbohren, damit etwas klarer wird, wie die 1+4+4 angesteuert werden können (und/oder im Wiki; der kurze Satz dazu wird scheinbar auch dort überlesen/nicht verstanden) (also in etwa so, wie FLOK das jetzt gebastelt hat).
Wenn das allg. Zustimmung findet, kann ich den ersten Teil gerne machen, für 2.@Wiki müßte ich erst umrüsten ::) .
Meinungen? Anderswo diskutieren (ist eigentlich hier OT)?
Zitat@FLOK
Das solltest du mit einer Kaufbridge ausprobieren können; wenn es da geht, klappt es auch mit der sidoh-bridge und entsprechenden Ports.
Besitze keine "Original"-Bridge.
Lediglich 5 Lampen und die Fernbedienung....
Als reiner "Nutzer" mit dem Hang zum basteln ist es leider oftmals wirklich schwierig sich zu orientieren.
Dieses Forum ist eine RIESENhilfe, aber auch hier ist die Erwartungshaltung recht hoch.
Da ich weder studiert habe, noch Elektroniker bin, bin ich für jeden WIKI-Eintrag dankbar.
Somit "DAUMEN hoch" :-)
Zitat von: FLOK am 07 November 2017, 14:58:37
Besitze keine "Original"-Bridge.
Lediglich 5 Lampen und die Fernbedienung....
Sorry, bin über das "FB wird in Port... eingetragen" geschlittert. Aber so in der Art müßte es gehen.
Es ist auch bei den Bridges so, dass die Kennung der Hardware (aka FB-ID) auf allen 4 Kanälen identisch ist und im Funkprotokoll lediglich die hinteren Bytes anders sind. (Wen's interessiert: steht irgendwo in der Hackaday-Darstellung zur openmili-Entwicklung, wie der Gesamtcode sich zusammensetzt).
@flok: korrekt!
@wiki: das ist offen! Bitte da reinschreiben:)
Zitat von: Beta-User am 07 November 2017, 14:54:43
1. Hinweis in's wiki zu den Milight-Artikeln, dass man besser Wifilight nutzen sollte
Wenn Milight blocking ist und man stattdessen Wifilight nutzen kann, dann bitte auf jeden Fall ein dicken Hinweis dazu ins Wiki. Blocking ist bäh...
Zitat von: krikan am 07 November 2017, 15:08:42
Wenn Milight blocking ist und man stattdessen Wifilight nutzen kann, dann bitte auf jeden Fall ein dicken Hinweis dazu ins Wiki. Blocking ist bäh...
Hatte mit den Original-Bridges immer mal wieder bis zu 10 Sek. Denkpause, und das mit 4 Bridges :( . Da aber die Bridge-Software von Karl da deutlich besser ist als das, was man kaufen kann, geht es ;) .
Im Ergebnis:
Wikihinweis ist jeweils ganz oben bei Bridge&Device, ob dick genug, mag jeder selber entscheiden, aber Wiki ist nach Vorgabe NEUTRAL...
Die Beispiel-Definitionen von FLOK habe ich @8899 als Beispiel in WifiLight@Wiki übernommen. Hoffe dass ich damit kein copyright verletze 8) .
Vielen Dank
Markenrechte wifilight liegen bei mir und ich erteile pauschal Absolution 😀
Ich muss nochmal nachfragen:
Nach welchen Kriterien werden die Kanäle zugeordnet?
Zitat
define WZ_Deckenlampe WifiLight RGBW2 bridge-V3:172.16.0.18:8800
attr WZ_Deckenlampe room MiLight
define Kanal2 WifiLight RGBW2 bridge-V3:172.16.0.18:8800
attr Kanal2 room MiLight
define Balkonstripe WifiLight RGBW2 bridge-V3:172.16.0.18:8800
attr Balkonstripe room MiLight
define Kanal4 WifiLight RGBW2 bridge-V3:172.16.0.18:8800
attr Kanal4 room MiLight
In dieser Reihenfolge habe ich meine Devices angelegt...
Allerdings verhält es sich nicht, wie erwartet.
Balkonstripe steuert Kanal1, was eigentlich der Deckenlampe entsprechen sollte. Der Balkonstripe (eigentlich auf Kanal 3)
läßt sich über Device "Kanal2" steuern... :-\
Die Kanäle/Bridges müssen doch unterschiedliche Ports haben oder nicht?
Also ich verwende die Milightbridge und da sieht es so aus.
define Milight01 MilightBridge 192.168.178.31:8899
attr Milight01 checkInterval 10
attr Milight01 event-on-change-reading state
attr Milight01 protocol udp
attr Milight01 room 096_Beleuchtung
attr Milight01 sendInterval 100
define Milight02 MilightBridge 192.168.178.31:8898
attr Milight02 checkInterval 10
attr Milight02 event-on-change-reading state
attr Milight02 protocol udp
attr Milight02 room 096_Beleuchtung
attr Milight02 sendInterval 100
define Milight03 MilightBridge 192.168.178.31:8897
attr Milight03 checkInterval 10
attr Milight03 event-on-change-reading state
attr Milight03 protocol udp
attr Milight03 room 096_Beleuchtung
attr Milight03 sendInterval 100
define Milight04 MilightBridge 192.168.178.31:8896
attr Milight04 checkInterval 10
attr Milight04 event-on-change-reading state
attr Milight04 protocol udp
attr Milight04 room 096_Beleuchtung
attr Milight04 sendInterval 100
Kann ja sein das das bei der Wifilight Bridge anders ist.
Gruß
Markus
Nein, bei dem Device, dass hier diskutiert wird, gibt es, so wie ich es nutze nur einen Port.
So klappt es:
Zitat
define Kanal1 WifiLight RGBW2 bridge-V3:172.16.0.18:8800
attr Kanal1 room MiLight
define Kanal2 WifiLight RGBW2 bridge-V3:172.16.0.18:8800
attr Kanal2 room MiLight
define Kanal3 WifiLight RGBW2 bridge-V3:172.16.0.18:8800
attr Kanal3 room MiLight
define Kanal4 WifiLight RGBW2 bridge-V3:172.16.0.18:8800
attr Kanal4 room MiLight
Jetzt entspricht der Kanal auch der Gruppe....ist also scheinbar alphabetisch ?
Arbeite ich eben mit Aliasen...
Ne, die Reihenfolge der Definition gilt. Group 1, 2, ...
ZitatNe, die Reihenfolge der Definition gilt. Group 1, 2, ...
Kann ich nicht bestätigen. (siehe 3 Posts vorher).
Was mir gerade auch Bauchschmerzen macht, ist die Tatsache, dass nach einem "shutdown restart" mein Licht plötzlich an ist...
by design. Sonst hat man ja keinen definierten Zustand.
Wird der Zustand vorm restart nicht gespeichert? Ist da immer on 100?
Müsste auch mal von Bridge/Device umsteigen. Da ist das meines erachtens nicht der Fall.
grüße
Matze
njet. fhem weiß nicht was zwischen shutdown und start mit der Lampe passiert benötigt dann jedoch einen definierten Zustand. Die Möglichkeiten waren: fhem Start: alle Lampen gehen aus: alle gehen an. Aus Sicherheitsgründen letzteres. Start ist ja die Ausnahme einer gut gepflegten fhem installation (weil die 24/7 durchläuft)
Ich bin unsicher warum das gelegentlich passiert (nicht immer).
Dadurch, dass ich die Fernbedienung auch nutze ist es wahrscheinlich, das sich Status
von FHEM und Lampen unterscheiden. Weil nicht synchron.
Da wäre der Ansatz mit MQTT zu suchen.
Leider habe ich wenig bis gar keine Ahnung davon.
Habe aus Jux mal im WEB-Interface des MilightHub (sidoh) meinen
MQTT-Server eingetragen und die Beispiele auf seiner Webseite übernommen.
Das Modul füttert dann den Broker.
Nur weiß ich nicht, wie man dann weiter vorgeht.
Vor allem, weil scheinbar nur der Wert HUE übertragen wird. Kein RGB. Somit auch nicht direkt
an WifiLight übertragbar (?)
Ich werde vorsichtshalber bei einem Reboot von FHEM die Lampen "AUS" schalten...
Wäre mit Lightscene nicht eine Möglichkeit gegeben den Zustand vor dem restart zu speichern?
Ich hab die milight-Hub-Bridge nun auch bei mir am laufen. Meinen RGB-WW-Bulb der mit der Original Bridge v3 bei mir seit über einem Jahr in Betrieb ist konnte ich problemlos mit irgendeiner ID pairen. Ein unpair mit der Original-Bridge war nicht nötig (mein gelesen zu haben das bis zu 4 ID's pro Bulb möglich sind). Jetzt hab ich hier seit längerem noch einen anderen RGB-W-Bulb mit Fernbedienung der sich weder mit der Original noch mit der Milight-Hub-Bridge pairen lässt. Auch eine v4-Bridge hab ich ausprobiert, hier ist auch kein pairen möglich. Ich spiele aber mit dem Gedanken mir weitere Lampen (Bulbs oder GU-10 Spots) zuzulegen. Das die v4-Bridge mit Fhem nicht geht ist klar, doch hab ich bisher noch nichts darüber lesen können das irgendwelche Lampen nicht mit der Selbstbau-Bridge oder der Versionen 3/4 kompatibel sind. Vlt. sind mir die Zusammenhänge mit dem neuen Protokoll auch nicht ganz klar. Auf was muss ich den jetzt beim Neukauf achten ?
ja das wäre auch meine Frage... habe vor ca. 1 Jahr die RGBW Bulbs geholt und über Milightbridge -Device gesteuert. Will nun auch auf das "Hexenmeister-Sido" Gateway umbauen. daher meine Fragen.. ;-)
1. Kann ich jede Miligt Bulb neu kaufen? Worauf muss ich achten?
2. Kann man auch eine zweite und dritte FB-ID als Server eintragen und entsprechend dann mehr "Kanäle" definieren?
3. eine MQTT HowTo wäre klasse...;-) Habe Mosquitto am laufen aber noch nicht definiert in FHEM.
Die Weboberfläche ist schon hammergeil :-)
Verwende ja das MySensors-Gateway von Hexenmeister. Da hatte ich nach dem flashen der Firmware nur das Problem das ich dauernd Timeouts beim Ping hatte und nicht auf die Weboberfläche kam. Habe dann den CE pin auf 4 geändert nun scheint es zu laufen. Kann es sein das da ein Zusammenhang besteht?
Gruß
Markus
Zu Deinem letzten Punkt: ja!
Zitat von: Markus. am 20 November 2017, 17:24:57
1. Kann ich jede Miligt Bulb neu kaufen? Worauf muss ich achten?
Vermutlich (!) gehen die aktuellen Typen mit dem längeren Protokoll nicht. Oder hat da schon jemand bessere Erfahrungen gemacht?
Zitat von: Markus. am 20 November 2017, 17:24:57
2. Kann man auch eine zweite und dritte FB-ID als Server eintragen und entsprechend dann mehr "Kanäle" definieren?
Das sollte doch eigentlich aus der Web-Oberfläche gut zu erkennen sein: Es wird pro Fernbedienung ein Port festgelegt, das ist dann jeweils eine Milight-Bridge (wenn man unbedingt dieses Modul verwenden will). Damit gingen dann 4 Milight-Devices.
Wobei die Sidoh-Variante den Vorteil zu haben scheint, dass man im Prinzip eine beliebige Anzahl Ports definieren kann.
muss ich mal testen..
Sollte ja dann so wie in dem Screenshot aussehen. Die Ports werden ja nicht automatisch definiert.
Hab dann einfach mal 8801 für die zweite FB genommen.
Mal sehen ob es so funktioniert.
Ich habe in meiner Stube nun 9 Lampen mit GU10 Fassung.
Nennen sich FUT018.
Aufgeteilt auf 2 Gruppen(also Kanäle): 4 Stück im Essbereich, 5 Stück im Wohnbereich.
Soweit ich das beurteilen kann, kannst du beliebig viele IDs generieren und somit auch Kanäle...
In Sachen MQTT brauche ich auch Hilfe. Komme hier von 100sten zum 1000sten.
MQTT-Server läuft und funktioniert. Angelegt in FHEM:
Zitatdefine myBroker MQTT 172.16.0.52:1883
attr myBroker room MQTT
Auf meinem Windows-Rechner die Software "mqttfx" installiert und mit dem Server verbunden.
Nun kann man schön beobachten, was dort so passiert....
Im "Milight Hub" habe ich den MQTT-Server ebenfalls eingetragen und
im Feld "mqtt_state_topic_pattern" folgendes eingetragen:
Zitatmilight/state/:device_id/:device_type/:group_id
Bei jeder Änderung ist nun ein Eintrag im Server zu beobachten....
Nur weiter bin ich noch nicht... :-[
ich will im Moment noch nicht meine funktionierenden Bulbs umkonfigurieren. Aber morgen mal eine neue pairen mit diesem Gateway.
Zu der Unterstützung des neueren Protokolls müsste das doch die Bestätigung sein..!?
Habe die Version 1.6.1 geflasht.
Zitat
You can select between versions 5 and 6 of the UDP protocol (documented here). Version 6 has support for the newer RGB+CCT bulbs and also includes response packets, which can theoretically improve reliability. Version 5 has much smaller packets and is probably lower latency.
Zum MQTT muss ich dann auch mal sehen wenn die andere Bulb verbunden ist. Muss auch mal schauen wie das mit der Reichweite aussieht. Habe die Sidoh-Firmware im Moment auf einem Hexenmeister-Board mit "normalen NRF24L01 laufen. Auf dem anderen (MililightBridge-Device) habe ich einen nrf24l01 + pa + lna. Und da ist es recht gut mit dem Empfang und senden.
Gruß
Markus
Mhh glaube ich habe mich zu früh gefreut.. :-(
Sniffen geht einwandfrei, aber wenn ich eine Bulb steuern will passiert nichts.
Habe es folgendermaßen probiert.
Es ist ja eine Bulb bereits gepairt mit der FB.
1. FB Id gesnifft und als Gateway Server eingetragen und gespeichert
2. ID kopiert und oben unter devices eingetragen dann auf Gruppe 1 (selbe Gruppe wie auf der FB)
3. RGBW angeklickt und versucht was zu schalten
Nix geht :-(
Den CE Pin habe ich auf 4 geändert.
Kann man da noch was versuchen ? Flash habe ich vorher gelöscht mit esptool.py und dann neu geflasht mit esp8266flasher.exe
Das komische ist auch, laut Doku kann man oben in den Devices die IDs speichern in Drop down. Geht auch nicht.
Gruß
Markus
Zitat von: Markus. am 21 November 2017, 18:47:57
Mhh glaube ich habe mich zu früh gefreut.. :-(
Sniffen geht einwandfrei, aber wenn ich eine Bulb steuern will passiert nichts.
Habe es folgendermaßen probiert.
Es ist ja eine Bulb bereits gepairt mit der FB.
1. FB Id gesnifft und als Gateway Server eingetragen und gespeichert
2. ID kopiert und oben unter devices eingetragen dann auf Gruppe 1 (selbe Gruppe wie auf der FB)
3. RGBW angeklickt und versucht was zu schalten
Nix geht :-(
Den CE Pin habe ich auf 4 geändert.
Kann man da noch was versuchen ? Flash habe ich vorher gelöscht mit esptool.py und dann neu geflasht mit esp8266flasher.exe
Das komische ist auch, laut Doku kann man oben in den Devices die IDs speichern in Drop down. Geht auch nicht.
Gruß
Markus
Speichern klappt bei mir auch nicht.
Hast du dran gedacht 0x vor deine gesniffte ID zu schreiben?
Andere Modi ausprobiert?
Gesendet von meinem Pixel mit Tapatalk
ja, sind ja rgbw bulbs aber die anderen modis habe ich auch probiert.
Die anderen Settings ausser CE = 4 bleiben doch Default oder?
sieht so aus als wenn der Empfang geht und das senden nicht. Werde morgen mal schauen was auf der seriellen Konsole so los ist.
Eventuell sieht man ja was. Wie gesagt, ist ein Hexenmeister Board mit fest verlötetem NRF und die ESP Firmware geflasht.
Meine irgendwo gelesen zu haben das man die Wemos Software auch nehmen kann, stimmt das?
Gruß
Markus
Ich nutze nicht die Hexenmeister-Hardware.
Ich musste nur den CE auf 4 setzen, danach konnte ich erst sniffen und dann auch senden.
sniffen geht ja einwandfrei...
Glaube ich baue mir zumtest mal eins mit einem Wemos D1 wenn ich Zeit habe ..:-(
gruß
markus
Kontrolliere nochmal die Verkabelung. Insbes. MOSI. Vielleicht wird ja wirklich nicht gesendet...
mmhh ist doch ein Hexenmeister Mysensors Gateway. Da ist nicht viel mit Verkabelung.
Gruß
Markus
Dann sollte das passen, v.a., wenn es vorher auch als MySensors-GW OK war...
ich werds nochmal löschen und neu flashen. Vielleicht ist ja da was schief gelaufen.
Hab die Pins mal "durch gepiepst" müsste so passen. MOSI ist auf 13, CE auf 4 CSN auf 15, MISO auf 12,SCK auf 14,
Gruß
Markus
Hallo Zusammen,
habe jetzt mal die Version 1.6.2 geflasht aber dort auch das selbe Problem. FB lässt sich sniffen. =x davor gesetzt CE Pin geändert.
Dann habe ich mal versucht von meinem anderen Gateway, auch von Hexenmeister, welches ja als Milightbridge bereits läuft, was zu sniffen. Aber von da empfange ich nichts. Wie gesagt FB einwandfrei. Kann es eventuell sein das meine alten Bulbs, die ca. 1,5 Jahre alt sind, ein anderes Protokoll haben und das gar nicht unterstützt wird? Das wäre aber dooooo* :-(
Wie gesagt:
- FB lässt sich sniffen
- Traffic vom anderen Gateway wird nicht gesnifft
Gruß
Markus
Das ist seltsam.
(Vorab: dass die Kanäle bei der SW-Version von der FB abweichen, war ja hier schon mal Thema; ggf. mußt du "nur" die weiteren Kanäle durchprobieren).
Ansonsten sollte an sich gelten: je älter die Bulbs, desto eher werden sie unterstützt. Das ganze klingt aber danach, als hättest du das "Glück", dass irgendwas bei dir funktechnisch anders ist als bei den meisten. Jedenfalls ich habe keine Idee, wie dem beizukommen ist...
Zur Erläuterung: Openmili selbst ist ein reverse-Engineering, damals basierend auf einem anderen Transceiver für 2.4 GHz (nämlich den, der bei der HW auch verbaut war). Dieser andere Transceiver wird dann wieder über den nRF wieder nur emuliert. Dabei kann ich mir gut vorstellen, dass die Timings im Ergebnis nicht ganz exakt sind und eben dann gar nicht mehr stimmen, wenn man das ganze 2x durch die ganze HW-SW-Kette laufen läßt. Evtl. reicht es, wenn der 2. Transceiver etwas außerhalb der Spec liegt. Dass die nRF-Chips - mind. auch China - eine erhebliche Serienstreuung aufweisen, ist ja (leider) bekannt...
Ich würde jetzt - vorausgesetzt, es werden weitere Kanäle benötigt - an deiner Stelle hergehen und das funktionierende GW mit der "andere " Software betanken. Dann muß man entweder umpairen oder eben die im Sketch von Karl jeweils voreingestellten Werte für Port und FB-ID verwenden.
viielen dank für die Tips und den irre guten Support den man hier immer bekommt !!
Also habe mir heute mal einen Wemos zusammengebaut und geflasht und schupps funktioniert :-)
Habe dann einen NRF24L01 mit Antenne geholt und muss schon sagen der Empfang und senden ist viel besser. Einen NRF mit Amplifier habe ich auch getestet aber da reicht die Power wohl nicht aus. Bin vom 5V port auf eine Adapterplatine für das NRF wo Spannungregler und so drauf sind. Muss mal schauen, das ich den NRF +pa+lna auch ans laufen bekomme damit (irgendwann).
Hat eventuell mal jemand ein Bespiel Define wo so alle Features für so eine RGB Bulb drin sind? Meine so einzelne Farben direkt ansteuern, Night und eventuell auch diese Szenen, wenn das geht.
Bei meinen Milight devices sieht das so wie in dem Bild aus.
Bezüglich der Gruppen/Kanäle habe ich noch eine Frage. Ich habe ja für RGBW vier Kanäle + All. Ist dann "ALL" für die Gruppe der an 5. Stelle definierte Kanal in FHEM?
Gruß
Markus
@FLOK
Bin gerade mit MQTT dran. Muss aber gestehen, das ist absolutes Neuland für mich. Hab Mosquitto am laufen und funktioniert auch soweit. Jedenfalls auf ein und dem selben Host Messages schicken. Hab dann einen Broker definiert mit IP des Hosts wo Mosquito läuft. In WebIF des Controllers habe ich dann soweit das eintragen was vorgeschlagen ist.
Sehe aber nirgendwo irgendwelche Messages. Mit MQTTFX sehe ich auch nichts. Kann zwar den Server subscriben und sehe die Statistiken des Mosquito-Servers. Aber keine Topics oder so...
Muss ich da auf FHEM Seite noch irgendwas machen?
Gruß
Markus
[quote ]
define myBroker MQTT 172.16.0.52:1883
attr myBroker room MQTT
[/quote]
Mehr habe ich nicht gemacht. Dann ein bisschen eingeschaltet und in mqttfx unten Mal auf Scan geklickt....dann listet er alle topics auf.(https://uploads.tapatalk-cdn.com/20171125/18ce6841f4efa69010493a5bbcaec75e.jpg)
Gesendet von meinem Pixel mit Tapatalk
ahh danke jetzt geht es :-)
Habe nur bei "mqtt_state_topic_pattern" was eingetragen, das war wohl der Fehler..
Gruß
Markus
Freut mich das es geklappt hat.
Bist du an dem Thema noch dran ?
Ich habe jetzt meine Fernbedienung erstmal lahmgelegt und steuere
die Lampen nur noch über FHEM (Tablet) und Alexa (Amazon Echo Dot).
Hallo Zusammen,
hab da ein Problem ;-)
Und zwar habe ich zwei FBs, beide IDs gesnifft und als Server eingetragen mit port 8800 und 8801.
Auf 8800 habe ich 4 Bulbs gepairt die auch einwandfrei funktionieren. dann habe ich auf der zweiten ID eine Bulb gepairt und wollte die nun in FHEM definieren, halt eben mit port 8801.
Da bekomm ich aber dann eine Fehlermeldung.
define WZ_Licht01 WifiLight RGBW2 bridge-V3:192.168.178.66:8801: no free slot at bridge-V3 (192.168.178.66) for RGBW2
Beim Neustart sieht das immer wie folgt aus
2017.12.07 08:27:52 3: WifiLight: requested bridge bridge-V3 at 192.168.178.66 already in use by SZ_Licht01, copy llCmdQueue
2017.12.07 08:27:52 3: WifiLight: requested bridge bridge-V3 at 192.168.178.66 already in use by SZ_Licht01, copy llCmdQueue
2017.12.07 08:27:52 3: WifiLight: requested bridge bridge-V3 at 192.168.178.66 already in use by SZ_Licht02, copy llCmdQueue
2017.12.07 08:27:52 3: WifiLight: requested bridge bridge-V3 at 192.168.178.66 already in use by SZ_Licht03, copy llCmdQueue
2017.12.07 08:27:52 3: WifiLight: requested bridge bridge-V3 at 192.168.178.66 already in use by SZ_Licht02, copy llCmdQueue
2017.12.07 08:27:52 3: WifiLight: requested bridge bridge-V3 at 192.168.178.66 already in use by SZ_Licht01, copy llCmdQueue
2017.12.07 08:27:52 3: WifiLight: requested bridge bridge-V3 at 192.168.178.66 already in use by SZ_Licht02, copy llCmdQueue
2017.12.07 08:27:52 3: WifiLight: requested bridge bridge-V3 at 192.168.178.66 already in use by SZ_Licht03, copy llCmdQueue
2017.12.07 08:27:52 3: WifiLight: requested bridge bridge-V3 at 192.168.178.66 already in use by BD_Licht01, copy llCmdQueue
2017.12.07 08:27:52 3: WifiLight: requested bridge bridge-V3 at 192.168.178.66 already in use by SZ_Licht01, copy llCmdQueue
2017.12.07 08:27:52 1: define WZ_Licht01 WifiLight RGBW2 bridge-V3:192.168.178.66:8801: no free slot at bridge-V3 (192.168.178.66) for RGBW2
Wie gesagt auf port 8800 habe ich SZ_Licht03 und BD_Licht01 auf 8801 (2.FB) Port 8801 wollte ich nun WZ_Licht01 definieren.
Hoffe da hat jemand eine Idee :-(
Gruß
Markus
Hallo zusammen,
ich habe mich jetzt durch mehrere Threads gelesen und weiß nicht so richtig weiter.
Ich habe das Projekt von Sidoh aufgebaut. Steuerung über WebIf und über curl funktioniert.
Das Problem ist: Ich habe weder eine RGB, RGBW oder anderes Vordefiniertes, sondern eine RGB+CCT FUT105.
Diese bekomme ich über Milightdevice nicht angesprochen.
Das funktioniert: curl -vvv -X PUT --data-binary '{"status": "on", "hue":50}' http://192.168.82.242/gateways/0x2222/rgb_cct/1
Kennt irgendjemand eine Lösung, bei der ich kein MQTT einsetzen muss?
Zitat von: projectsun am 18 Januar 2018, 21:18:27
Kennt irgendjemand eine Lösung, bei der ich kein MQTT einsetzen muss?
Es gibt zwar hier (https://forum.fhem.de/index.php/topic,84979.0.html) auch eine Lösung mit HTTPMOD, aber da das auch Neuland ist und den Status "nur" alle 30 sec. aktualisiert, dachte ich, dass es evtl. auch nicht verkehrt wäre, mit MQTT anzufangen.
Mein ESP läuft jetzt auch mit der Firmware von sidoh (1.7.0-dev3). Jetzt wollte ich mit MQTT die Milight-Bridge/-Device-Lösung vollends loswerden.
Aber zum einen ist die Installation der Perl-Pakete schon Mist (habe das mit dh-make-perl gemacht, damit ich das notfalls auch wieder aus dem System bekomme). Aber schon beim Betrieb ohne FHEM scheitert es daran, dass
a) nicht alle FB's erkannt werden (die 4-fach sind kein Problem, aber ich habe hier eine 1-fach-FB, die zwar die Bulb steuert und den ESP zum Blinken bringt, aber gesniffte Info sehe ich nicht...)
b) die erkannten FB-codes scheinbar nicht an den broker (mosquitto) weitergegeben werden. Habe erst mal kein username/passwort gesetzt und verwende die Standardeinstellungen für die drei Bereiche wie Markus. und die IP des Servers.
Das testen mit "mosquitto_pub -h localhost -t milight -m "irgendwas"" funktioniert, dasselbe geht auch mit Angabe der Server-IP. Aber von der Bridge kommt leider nix bei mosquitto_sub an...
Hat jemand einen Tip?EDIT: hat sich dahingehend erledigt, dass ich das doch nur mit HTTPMOD lösen werde.
Gruß, Beta-User
So, eine Iteration weiter:
Die HTTPMOD-Geschichte funktioniert zwar in Senderichtung einwandfrei, aber leider bekomme ich keine vernünftige Rückmeldungen über geänderte Stati und die Schieberegler des HTTPMOD-Devices sind auch immer "ganz links". Ist also doch keine wirkliche Verbesserung gg. Milight/Wifilight.
Habe daher doch den Mosquitto nochmal summen lassen und bekomme auch den Weg Bridge->Mosquitto hin.
Jetzt habe ich aber ein paar Themen, bei denen ich noch nicht so richtig weiß, wie dem am sinnvollsten beizukommen ist:
- Die Bridge liefert und erwartet json-Blobs als Info, updates sehen z.B. so aus: {"status":"on"}. Nach meinem Recherchestand kann aber das aktuelle MQTT_DEVICE-Modul kein json. Was vorhanden ist, ist eine ältere Modifikation des MQTT_DEVICE-Moduls hier (https://forum.fhem.de/index.php/topic,75144.msg674649.html#msg674649), das das (sogar für diese Bridge) (sendeseitig) könnte. Jetzt wollte ich nicht unbedingt einen ggf. schon wieder veralteten Stand einbauen, zumal das Thema, json versenden (und empfangen) zu können auch andere MQTT-Lösungen betrifft. Und die Empfangsseite scheint dort nicht implementiert zu sein (s.u.).
- Irgendwie bekomme ich die Bridge nicht überredet, andere als die voreingestellten Werte zu senden (z.B.: statt "brightness" von [0-255] wäre mir "level" mit [0-100] sympatischer). (Ist aber vermutlich eher ein firmware- oder 60cm-Problem).
- zu guter letzt: hat schon jemand eine sinnvolle Rückkanalauswertung am laufen?
Wenn ja: Bitte um code-Schnipsel. Insbesondere wäre interessant, ob ihr auch erweiterte mapping-Beispiele habt, also sowas: Wenn die Gruppe 0x1234 angeschaltet wird, kommt das auf der .../0 zurück. Diese Info gehört dann aber noch auf alle Einzeldevices dieser Gruppe als Status übertragen (.../1 bis .../4). Und dann soll es noch Fälle geben, in denen dieselbe Bulb auf mehrere FB's hört (also wenn das Gerät, das auf Kanal 4 aus Gruppe 0x1234 hört, auch mit Kanal 3@0xABCD gekoppelt ist, sollte ein "off" auf letzteren ja auch bei einem FHEM-Gerät ankommen.
Hat da jemand (ggf. Teillösungen) für gefunden bzw. wo muß ich sonst noch suchen?
EDIT: Weitgehend gelöst, siehe link im Folgebeitrag.
Gruß, Beta-User
Kurzer Update: Die MQTT-Implementierung läuft - zumindest auf den ersten Blick - jetzt super!
Details hier, (https://forum.fhem.de/index.php/topic,75144.msg785444.html#msg785444) über Unterstützung bei den "Restarbeiten" würde ich mich sehr freuen ;D .
Gruß, Beta-User
da werde ich mich mal dran hängen :-)
gruß
Markus
Zitat von: Markus. am 23 März 2018, 11:39:42
da werde ich mich mal dran hängen :-)
Gerne!
Hast du den MQTT-Server schon am laufen?
Wenn nein: Habe mir die Schritte mal stichwortartig aufgeschrieben, um zu einem funktionsfähigen Mosquitto zu kommen und dabei die Perl-Module den "Debian-way" zu installieren (kann sein, dass eines der Pakete (simple?) bereits im Repo ist):
sudo apt-get install dh-make-perl
dh-make-perl --install --cpan Net::MQTT::simple
dh-make-perl --install --cpan Net::MQTT::Message
dh-make-perl --install --cpan Net::MQTT::Constants
sudo dpkg -i libmodule-pluggable-perl*.deb
sudo dpkg -i libnet-mqtt-simple-perl*.deb
sudo dpkg -i libnet-mqtt-perl*.deb
Server auf ESPMH eintragen, Standardvorgaben für Mosquitto-Topics
mosquitto_sub -h <Server-IP> -d -t milight/updates/+/+/+
Dann sollten FB-Codes usw. übertragen werden bzw. auf der Konsole erscheinen...
Wenn's klappt, poste ich evtl. heute am späteren Abend noch eine Modul-Version, die einem das Anlegen der Attribute abnimmt 8) . Ich habe da einige Kanäle zu konfigurieren, da ist sowas hilfreich...
Ja Mosquitto habe ich auf Stretch schon eine Weile laufen wegen meinem Heizungszeugs.
Wird das nacher mal testen mit dem subscriben der Milight Messages.
Gruß und Danke
Markus
Zitat von: sash.sc am 02 November 2017, 18:42:23
Hallo zusammen !
Habe es jetzt mit FHEM und dem Modul WIFILIGHT und der Firmware von Sido aus den vorhergehenden Post´s am laufen bekommen.
Mit eine Server imm WEBIF (Tip von Gunther) war schon nicht schlecht. Das wichtigste dabei ist aber nicht die Adresse 0x1 zu nehmen, sondern die gesniffte ID, insofern es möglich war zu sniffen.
Also:
1. Vorraussetzung ist das die FW von Sidoh geflasht ist und erreichbar ist.
2. Wenn man keine FB zum sniffen hat, dann eine ID ausdenken (z.B. 0x2000), dann Lampen pairen
3. zu beachten ist dann noch die CS/CN Leitung umstecken oder den PIN in die WEBIF eintragen. (tip von Hexenmeister zuvor)
4. Dann den Server in der WEBIF eintragen. Ganz wichtig, im Server die ID des devices eintragen, welches man schalten will, mit PORT angabe.
5. Das ganze speichern.
6. Dann mit dem Modul WIFLIGHT und der PortAngabe hinter IP ein Device einrichten, oder das Ganze über das Milight Modul !!!!
Hoffe ein wenig weiter geholfen zu haben !!!
Gruß
Sascha
Hallo,
bin leider auch in die Falle mit der neuen iBox2 getappt und habe mir einen ESP mit NRF24L01 und der Software von sidoh zusammen gesteckt.
In der Web-Oberfläche kann ich die Lampen auch einwandfrei steuern. Nun möchte ich natürlich FHEM auch in die Lage versetzen alles schalten zu können.
Leider gelingt mir das weder mit dem Wifilight noch mit dem MiLight Modul. Ich mache sicher noch was falsch. Könnte mir jemand einen Tipp geben?
Als Leuchtmittel verwende ich eine RGBCCT Lampe im E27 Format https://www.amazon.de/dp/B0756YNXB3/ref=cm_sw_em_r_mt_dp_U_8vzMDb7AS5829 (https://www.amazon.de/dp/B0756YNXB3/ref=cm_sw_em_r_mt_dp_U_8vzMDb7AS5829)
und zwei GU5.3 Strahler https://www.amazon.de/dp/B01HN75JXA/ref=cm_sw_em_r_mt_dp_U_MxzMDb7NASSQH (https://www.amazon.de/dp/B01HN75JXA/ref=cm_sw_em_r_mt_dp_U_MxzMDb7NASSQH).
In FHEM habe ich es so definiert:
#=====================================================================
# Milight Hub:
# https://blog.christophermullins.com/2017/02/11/milight-wifi-gateway-emulator-on-an-esp8266/
# https://forum.fhem.de/index.php?topic=76817.0
#=====================================================================
define MilightHub MilightBridge 192.168.178.88
attr MilightHub room 99_Devices
define Whz_Strahler MilightDevice RGBW MilightHub 5
attr Whz_Strahler room 01_Wohnzimmer
Auf dem MilightHub (ESP) habe ich eigentlich nur die Device ID von der alten iBox2 gesnifft und eingetragen, damit der ESP die Lampen kennt.
Danke schon mal im Vorraus!
Grüße
Andreas
Hast du UDP entsprechend auf dem Hub definiert? Jedenfalls bei Wifilight läßt sich auch der Port angeben, das muß eben zusammenpassen...
Ansonsten würde ich empfehlen, das via MQTT2_DEVICE zu machen, wenn du keine Transitions usw. nutzen willst. (Siehe Praxisbeispiele zu MQTT2_DEVICE im Wiki.) Jedenfalls nicht mit MiLight-Bridge/device, das blockiert teilweise.
Gruß, Beta-Usr
Gerade erst gesehen...
Ich glaube wifilight geht mit der Bridge nicht weil die Bridge auch die neuen Protokolle braucht. Ich verwende die jedenfalls nur via mqtt
Hmmm,
ich hatte das so verstanden, dass der Milight-Hub auch auf UDP-Ports hört, man diese aber dort einstellen muß, und hätte darauf getippt, dass @anoll das nicht gemacht hatte (und auch in FHEM nichts angegeben). Aber wenn der Befehl erst mal bei der Bridge angekommen ist (also auf beiden Seiten eingestellt), müßte ihr das egal sein, ob das "altes", "neues" oder ggf. "ganz neues" Protokoll ist (u.a. die 99-kanalige FB hat wohl nochmal ein anderes Funkprotokoll).
Aber mangels Rückmeldung von anoll werden wir da wohl weiter im Dunkeln tappen, bis da was an Info kommt...
also ich hab die Milight Bridge mit der Sido Software (letzte Version) mit Wifilight am laufen. Habe aber ältere Bulbs und weiß nicht ob sich bei den neuen was geändert hat. Hatte oben nur das Problem das UDP Ports nicht unterstützt wurden, das wurde aber durch Herrmann damals schnell gefixt...
Gruß
Markus
Mit den alten Lampen ist möglich, die neuen werden nicht laufen weil das alte Protokoll zb keine Sättigung kann. Aber über mqtt geht's ja perfekt
Hi zusammen,
ich habe die Tage mir auch eine MilightBridge von Sido (https://github.com/sidoh/esp8266_milight_hub) mit einem D1 Mini und dem NRF24L01+ gebastelt.
Übers Webinterface ist die Bridge erreichbar.
Mit einer ausgedachten Device ID (0x2000 und 0x2001) habe ich meine vorhandenen MiLight RGBW Controller (FUT038) gepairt und kann sie im Webinterface steuern. unter Settings habe ich für jede DeviceId ein Port angelegt.
Was ich leider noch nicht hin bekommen habe ist die Geräte in FHEM entweder über Milight mit Bridge oder WiFiLight anzusprechen.
Wenn ich über Milight Konfiguriere sieht das in ca so auch:
define MyMilightHub MilightBridge 192.168.0.228
attr MyMilightHub room Kueche
attr MyMilightHub group MilightDevice
define MBaum MilightDevice RGBW MyMilightHub 5
attr MBaum group MilightDevice
attr MBaum room Kueche
define Kanal2 MilightDevice RGBW MyMilightHub 6
attr Kanal2 group MilightDevice
attr Kanal2 room Kueche
define Kanal3 MilightDevice RGBW MyMilightHub 7
attr Kanal3 group MilightDevice
attr Kanal3 room Kueche
define Kanal4 MilightDevice RGBW MyMilightHub 8
attr Kanal4 group MilightDevice
attr Kanal4 room Kueche
auch wenn ich beim Device MyMilightHub das Port 48899 oder 8899 oder 8801 angebe... passiert nichts.
wenn ich das ganze über WiFiLight versuche was in etwa so aussieht:
define Kanal1 WifiLight RGBW2 bridge-V3:192.168.0.228:8899
define Kanal2 WifiLight RGBW2 bridge-V3:192.168.0.228:8899
define Kanal3 WifiLight RGBW2 bridge-V3:192.168.0.228:8899
define Kanal4 WifiLight RGBW2 bridge-V3:192.168.0.228:8899
werden die Lampen auch nicht geschaltet.
Für mich stellt sich noch die Frage wer jetzt genau definiert das Device 0x2000 oder 0x2001 angesprochen werden soll.
mit einem set...on oder off blinkt der D1 Mini zwar aber er schaltet nichts.
Ich möchte nicht erst einen Matt einrichten nur um die Lampen laufen zu lassen.
zur Info...mit meiner vorhanden originalen V3 Bridge funktioniert alles mit folgender cfg:
### MilightBridge
define MilightBridge MilightBridge 192.168.0.38
attr MilightBridge checkInterval 10
attr MilightBridge event-on-change-reading state
attr MilightBridge protocol udp
attr MilightBridge sendInterval 100
### Device Kueche
define MiLightKueche MilightDevice RGBW MiLightBridge 6
attr MiLightKueche IODev MilightBridge
attr MiLightKueche devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
attr MiLightKueche event-on-change-reading state,transitionInProgress
attr MiLightKueche lightSceneParamsToSave hsv
attr MiLightKueche restoreAtStart 1
attr MiLightKueche room Homekit,Kueche,alexa
attr MiLightKueche webCmd on:off:dim:hue:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffff00
### Device Baum
define MiLightBaum MilightDevice RGBW MiLightBridge 5
attr MiLightBaum IODev MilightBridge
attr MiLightBaum devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
attr MiLightBaum event-on-change-reading state,transitionInProgress
attr MiLightBaum lightSceneParamsToSave hsv
attr MiLightBaum restoreAtStart 1
attr MiLightBaum room Homekit,Kueche,alexa
attr MiLightBaum webCmd on:off:dim:hue:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffff00
### Device Baum
define MiLightDecke MilightDevice RGBW MiLightBridge 8
attr MiLightDecke IODev MilightBridge
attr MiLightDecke devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
attr MiLightDecke event-on-change-reading state,transitionInProgress
attr MiLightDecke lightSceneParamsToSave hsv
attr MiLightDecke restoreAtStart 1
attr MiLightDecke room Homekit,Kueche,alexa
attr MiLightDecke webCmd on:off:dim:hue:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffff00
### Device Bett
define MiLightBett MilightDevice RGBW MiLightBridge 7
attr MiLightBett IODev MilightBridge
attr MiLightBett devStateIcon {(MilightDevice_devStateIcon($name),"toggle")}
attr MiLightBett event-on-change-reading state,transitionInProgress
attr MiLightBett lightSceneParamsToSave hsv
attr MiLightBett restoreAtStart 1
attr MiLightBett room Homekit,Schlafzimmer,alexa
attr MiLightBett webCmd on:off:dim:hue:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffff00
Bitte helft mir bei der Einbindung in FHEM ohne MQTT
Da Milight_bridge blocking ist, sollte man mAn. heutzutage immer Wifilight nehmen, wenn man kein MQTT haben will. Hatte das die im Einsatz, meine aber, dass der Maintainer extra die Portangabe eingeführt hat, damit man die Sidoh-Bridge so universell nutzen kann wie sie konzipiert ist.
Also unter "UDP" im Hub je Fernbedienungs-ID einen Port anlegen und dann eben auch genau diesen Port (und nicht die Standardports) im Wifilight-Device angeben:
0x2000 => Port 8899 im Hub => define Kanal1 WifiLight RGBW2 bridge-V3:192.168.0.228:88990x2001 => Port 8898 im Hub => define KanalB1 WifiLight RGBW2 bridge-V3:192.168.0.228:8898
Einen MQTT2_SERVER anzulegen ist aber auch kein Hexenwerk und erzeugt auch keine nennenswerte Systemlast...
Hi, Danke für deine Antwort.
Ich habe jetzt Mittlerweile mein FHEM mit MQQT2_Server ausgestattet und folgendes in die milight bridge eingetragen:
MQTT server
192.168.0.29:1883
MQTT topic pattern
milight/:device_id/:device_type/:group_id
MQTT update topic pattern
milight/updates/:hex_device_id/:device_type/:group_id
MQTT state topic pattern
MQTT Client Status Topic
milight/LWT
Publish state messages with retain flag Enabled
Client Status Messages Mode Detailed
nach einem Submit und einem ändern eines Wertes im WI zeigte es mir ein neues Device unter MQTT an welches ich mit dem Template esp_milight_hub_bridge ausgestattet habe.
beim erneuten senden eines Befehls aus dem WebIF der ESPBridge wurde wieder ein neues Device angelegt mit MQTT2_milight_0x1000_1 welches ich mit dem Template esp_milight_hub_rgbw_bulb ausgestattet habe.
die Device ID habe ich übers WebIF erstellt und mit dem jeweiligen RGBW controller gepaart zb auf die 0x1000.
nur leider kann ich in FHEM klicken was ich will...nichts verändert sich an den LEDS. Wenn ich im WebIf der ESPBridge werte verändere gehts.
was kann ich noch tun damit die ESPBridge meine über FHEM gesendeten Daten auch an die LEDS überträgt.
Ein List noch von MQTT2_milight_0x1000_1 zeigen (das immer aufschlussreicher als ein Screenshot) und einfach mal schauen ob was im LogFile steht.
Wenn du in der "ESPBridge" (Oben) Start Sniffing startest kommt da was an wenn du in Fhem irgendeinen Befehl absetzt ?
Bei MQTT state topic pattern ging was schief, was steht da drin ?
ein list ergibt:
Internals:
.eventMapCmd Weiss:noArg Nacht:noArg white:noArg
CFGFN
CID milight_0x1000_1
DEF milight_0x1000_1
DEVICETOPIC MQTT2_milight_0x1000_1
FUUID 5ffa320a-f33f-8acd-cdbe-a0ca32ec1a6ab739
IODev MQTT2_FHEM_Server
NAME MQTT2_milight_0x1000_1
NR 30904
STATE set_off
TYPE MQTT2_DEVICE
.attraggr:
.attrminint:
.userReadings:
HASH(0x40272e0)
HASH(0x546f730)
OLDREADINGS:
READINGS:
2021-01-09 23:45:31 associatedWith MQTT2_milight_hub_11377978
2021-01-09 23:46:02 attrTemplateVersion 20200522 or prior
2021-01-09 23:46:23 brightness set 165
2021-01-09 23:46:37 hue set 129
2021-01-09 23:45:31 level 99
2021-01-09 23:46:48 state set_off
2021-01-09 23:45:31 status ON
Attributes:
IODev MQTT2_FHEM_Server
comment To switch device also on when changing brightness, change payload pattern to {"status":"ON","$EVTPART0":"$EVTPART1"} or add a new element to setList, similar to brightness, e.g.brightness_on and change payload pattern as described.
devStateIcon {zigbee2mqtt_devStateIcon255($name,"hex",1)}
eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/
genericDeviceType light
homebridgeMapping Brightness=brightness::brightness,maxValue=100,factor=0.39216,delay=true
icon light_control
model esp_milight_hub_rgbw_bulb
readingList MiBaum/states/0x1000/rgb_cct/1:.* { json2nameValue($EVENT) }
MiBaum/states/0x1000/rgb_cct/0:.* { json2nameValue($EVENT) }
MiBaum/updates/0x1000/rgb_cct/1:.* { json2nameValue($EVENT) }
MiBaum/updates/0x1000/rgb_cct/0:.* { json2nameValue($EVENT) }
room MQTT2_DEVICE
setExtensionsEvent 1
setList on:noArg MiBaum/0x1000/rgb_cct/1 {"status":"ON"}
on_transition:slider,3,10,3600 MiBaum/0x1000/rgb_cct/1 {"status":"ON","transition":$EVTPART1}
off:noArg MiBaum/0x1000/rgb_cct/1 {"status":"OFF"}
off_transition:slider,3,10,3600 MiBaum/0x1000/rgb_cct/1 {"status":"OFF","transition":$EVTPART1}
brightness:colorpicker,BRI,0,15,255 MiBaum/0x1000/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
hue:colorpicker,HUE,0,1,359 MiBaum/0x1000/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
command:uzsuSelectRadio,Weiss,Nacht MiBaum/0x1000/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
setStateList on off
userReadings hex:color_r.* {Color::rgb2hex(ReadingsVal($name,"color_r",255),ReadingsVal($name,"color_g",255),ReadingsVal($name,"color_b",255))}, hue:bulb_mode.*white {"0"}
webCmd brightness:hue:command
wenn ich sniffing starte und in FHEM ein Befehl abgebe kommt nichts an der Bridge an oder wird gesendet
auffällig ist zb:
2021-01-09 23:46:48 state set_off
2021-01-09 23:45:31 status ON
mache ich ein set off steht im state set off...aber der Status ist nach wie vor ON da die Lampen auch noch an sind.
Internals:
.eventMapCmd Weiss:noArg Nacht:noArg white:noArg
CFGFN
CID milight_0x1000_1
DEF milight_0x1000_1
DEVICETOPIC MQTT2_milight_0x1000_1
FUUID 5ffa320a-f33f-8acd-cdbe-a0ca32ec1a6ab739
IODev MQTT2_FHEM_Server
NAME MQTT2_milight_0x1000_1
NR 30904
STATE set_off
TYPE MQTT2_DEVICE
.attraggr:
.attrminint:
.userReadings:
HASH(0x40272e0)
HASH(0x546f730)
OLDREADINGS:
READINGS:
2021-01-09 23:45:31 associatedWith MQTT2_milight_hub_11377978
2021-01-09 23:46:02 attrTemplateVersion 20200522 or prior
2021-01-09 23:46:23 brightness set 165
2021-01-09 23:46:37 hue set 129
2021-01-09 23:45:31 level 99
2021-01-09 23:46:48 state set_off
2021-01-09 23:45:31 status ON
Attributes:
IODev MQTT2_FHEM_Server
comment To switch device also on when changing brightness, change payload pattern to {"status":"ON","$EVTPART0":"$EVTPART1"} or add a new element to setList, similar to brightness, e.g.brightness_on and change payload pattern as described.
devStateIcon {zigbee2mqtt_devStateIcon255($name,"hex",1)}
eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/
genericDeviceType light
homebridgeMapping Brightness=brightness::brightness,maxValue=100,factor=0.39216,delay=true
icon light_control
model esp_milight_hub_rgbw_bulb
readingList MiBaum/states/0x1000/rgb_cct/1:.* { json2nameValue($EVENT) }
MiBaum/states/0x1000/rgb_cct/0:.* { json2nameValue($EVENT) }
MiBaum/updates/0x1000/rgb_cct/1:.* { json2nameValue($EVENT) }
MiBaum/updates/0x1000/rgb_cct/0:.* { json2nameValue($EVENT) }
room MQTT2_DEVICE
setExtensionsEvent 1
setList on:noArg MiBaum/0x1000/rgb_cct/1 {"status":"ON"}
on_transition:slider,3,10,3600 MiBaum/0x1000/rgb_cct/1 {"status":"ON","transition":$EVTPART1}
off:noArg MiBaum/0x1000/rgb_cct/1 {"status":"OFF"}
off_transition:slider,3,10,3600 MiBaum/0x1000/rgb_cct/1 {"status":"OFF","transition":$EVTPART1}
brightness:colorpicker,BRI,0,15,255 MiBaum/0x1000/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
hue:colorpicker,HUE,0,1,359 MiBaum/0x1000/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
command:uzsuSelectRadio,Weiss,Nacht MiBaum/0x1000/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
setStateList on off
userReadings hex:color_r.* {Color::rgb2hex(ReadingsVal($name,"color_r",255),ReadingsVal($name,"color_g",255),ReadingsVal($name,"color_b",255))}, hue:bulb_mode.*white {"0"}
webCmd brightness:hue:command
Warum steht da in den Topic-Pfaden MiBaum ?
Wurde das Device so angelegt oder hast den Pfad so händisch angepasst ?
Da sollte eigentlich milight stehen.
Ich bin davon ausgegangen das ich den Name frei vergeben kann zur besseren Identifikation.
Habe das device neu angelegt und milight eingegeben.
Internals:
.eventMapCmd Weiss:noArg Nacht:noArg white:noArg
CFGFN
CID milight_0x1000_1
DEF milight_0x1000_1
DEVICETOPIC MQTT2_milight_0x1000_1
FUUID 5ffadc01-f33f-8acd-5e74-69b5593a58fb8005
IODev MQTT2_FHEM_Server
NAME MQTT2_milight_0x1000_1
NR 69757
STATE set_on
TYPE MQTT2_DEVICE
.attraggr:
.attrminint:
.userReadings:
HASH(0x5551908)
HASH(0x6a3f8d8)
OLDREADINGS:
READINGS:
2021-01-10 11:50:41 associatedWith MQTT2_milight_hub_11377978
2021-01-10 11:51:53 attrTemplateVersion 20200522 or prior
2021-01-10 11:50:41 brightness 252
2021-01-10 11:54:27 hue set 0
2021-01-10 11:50:41 level 99
2021-01-10 11:52:14 on_transition set 3
2021-01-10 11:54:25 state set_on
2021-01-10 11:50:41 status ON
Attributes:
IODev MQTT2_FHEM_Server
comment To switch device also on when changing brightness, change payload pattern to {"status":"ON","$EVTPART0":"$EVTPART1"} or add a new element to setList, similar to brightness, e.g.brightness_on and change payload pattern as described.
devStateIcon {zigbee2mqtt_devStateIcon255($name,"hex",1)}
eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/
genericDeviceType light
homebridgeMapping Brightness=brightness::brightness,maxValue=100,factor=0.39216,delay=true
icon light_control
model esp_milight_hub_rgbw_bulb
readingList milight/states/0x1000/rgb_cct/1:.* { json2nameValue($EVENT) }
milight/states/0x1000/rgb_cct/0:.* { json2nameValue($EVENT) }
milight/updates/0x1000/rgb_cct/1:.* { json2nameValue($EVENT) }
milight/updates/0x1000/rgb_cct/0:.* { json2nameValue($EVENT) }
room MQTT2_DEVICE
setExtensionsEvent 1
setList on:noArg milight/0x1000/rgb_cct/1 {"status":"ON"}
on_transition:slider,3,10,3600 milight/0x1000/rgb_cct/1 {"status":"ON","transition":$EVTPART1}
off:noArg milight/0x1000/rgb_cct/1 {"status":"OFF"}
off_transition:slider,3,10,3600 milight/0x1000/rgb_cct/1 {"status":"OFF","transition":$EVTPART1}
brightness:colorpicker,BRI,0,15,255 milight/0x1000/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
hue:colorpicker,HUE,0,1,359 milight/0x1000/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
command:uzsuSelectRadio,Weiss,Nacht milight/0x1000/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
setStateList on off
userReadings hex:color_r.* {Color::rgb2hex(ReadingsVal($name,"color_r",255),ReadingsVal($name,"color_g",255),ReadingsVal($name,"color_b",255))}, hue:bulb_mode.*white {"0"}
webCmd brightness:hue:command
Seh leider nicht woran es liegt.
Glaubs zwar nicht, wenn du MQTT2_milight_0x1000_1 einfach nochmal löschst, in der Bridge einmal schaltest das das Device wieder neu angelegt wird und dann das esp_milight_hub_rgbw_bulb-Template anwendest (ohne zuvor was händisch zu ändern), klappts vlt. dann.
Wenn ich die LEDS im webinterface veränder und wieder zu FHEM gehe hat sich der Status der Leuchte auch geändert. anscheinend geht nur nicht das senden eines Befehls über FHEM.
Kann das an den settings in der Bridge liegen?
MQTT topic pattern
milight/:device_id/:device_type/:group_id
MQTT update topic pattern
milight/updates/:hex_device_id/:device_type/:group_id
MQTT state topic pattern
milight/states/:hex_device_id/:device_type/:group_id
MQTT Client Status Topic
Milight/LWT
Nützt es was wenn ic mal die Json aus dem backup von der bridge hoch lade?
rgb_cct
Hast du jetzt falsch angelernt (dann vermutlich RGBW unter Remote Type wählen und nochmal pairen) oder das falsche Template gewählt ?
edit:
wobei, schalten (ein/aus) sollte eigentlich (mein ich) egal mit welchem der beiden Templates möglich sein
Hallo,
hier ist ein Beispiel (https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Einf.C3.BChrung:_MQTT_bzw._MQTT2_in_FHEM) von Beta-User (https://forum.fhem.de/index.php/topic,103493.0.html).
Danach habe ich auch meine MiLight Fernbedienung und die MilightBridge von Sido (https://github.com/sidoh/esp8266_milight_hub) eingerichtet.
Und kann über die Frnbedienung verschieden Geräte schalten, Dimmen und Farbe ändern.
pejonp
ah cool, danke an alle. Es funzt!!!
mein Fehler war das ich beim paaren der Geräte alles auf Gruppe 1 gepaart habe. also 0x1000 auf rgbw Gruppe 1 und 0x1001 auf rgbw Gruppe 1.
habe jetzt jedem device eine eigene Gruppe verpasst und siehe da. es geht!!!
Ich dachte nur das ich mit dieser Selbstbau Bridge so viele Lampen wie ich will paaren kann. zb LED1 0x1000 und LED 0x1001 und LED 0x1002 und so weiter
ich habe vor in meiner Neubau Garage 4 Neue GU10Spots zu meinen vorhandenen 4 LED Stripes im Haus zu installieren.