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

[schka17]

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

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

Ich 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
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, 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.

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
Code: [Auswählen]

#define SOFTSPI

gesetzt sein!!!!
Pin-Belegung im Sketch.

Cheers,

Pula

 

 

[hexenmeister]

Gute Arbeit! Wer hätte gedacht, wofür man das MySensors-Gateway so alles einsetzen kann
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?

[schka17]

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.

[Beta-User]

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:

Code: [Auswählen]

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

[schka17]

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.

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.

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.

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.

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

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

[Beta-User]

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

es gibt ja auch ein mysensor Projekt das Ausbaupotential hat 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...

[schka17]

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

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.

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.

Code: [Auswählen]

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

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.

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

[Beta-User]

damit kannst du aber theoretisch schon mal deine 4 Milight Bridges gegen 1 nodemcu oder 1 WlanMSGW austauschen.

Super-Sache, das!  Das werde ich vermutlich zeitnah in Angriff nehmen, die Bridges nerven wirklich ungemein...

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!

[schka17]

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

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.

 

[Beta-User]

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)
Lesen macht schlau, war unten schon dabei, sorry...

zumal 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) ...

[herrmannj]

 

Man kann es nicht besser sagen !

[Beta-User]

Man kann es nicht besser sagen !

ich glaub', ich will besser keine nähere Ausführung, was "es" konkret bedeutet

[schka17]

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

[Beta-User]

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

[schka17]

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