Hi zusammen,
ich hänge gerade etwas, vielleicht könnt ihr mir helfen...
- Ich habe mir einen Arduino Nano als Ersatz für die Milight Bridge zusammen gebastelt
- Auf dem Nano läuft der openmili sketch
- Der Nano hängt direkt am FHEM Pi
- Über die Arduino Software kann ich meine Milights schalten
- Ich lasse auf dem Pi die mit openmili gelieferte "host" Anwendsung laufen
- Wenn ich in FHEM die IP in der DEF der MilightBridge auf die von openMili (sprich den FHEM Server) ändere lassen sich die Milights weiterhin wunderbar über FHEM schalten (nur jetzt via openmili statt der Milight Bridge, bis auf ein Problem:
- ==> Wenn ich ein "off" sende, wird die Birne (ich verwende RGBWs) runter gedimmt, aber nicht ausgeschaltet...
Hat jemand ähnliche ERfahrungen gemacht? Wie nutzt ihr openmili mit FHEM?
Danke,
Grüße,
Oli
Moin Oli,
interessanter Ansatz!
Soweit mir bekannt, ist bislang der einzige Einsatz von openmili hier die ESP-Bridge von Schka17 (https://forum.fhem.de/index.php/topic,58742.0.html). Damit funktioniert die volle Bandbreite einschließlich Aus wunderbar und es hat den Vorteil, dass man im Prinzip beliebig viele Bridges damit ersetzen kann (im Moment/aktuellen Sketch 4).
Nachteil ist, dass es im WLAN hängt.
Das würde ich auch gerne in eine serielle/USB Lösung ändern, wobei ich (schlicht weil ich das mittlerweile halbwegs kenne) eher MySensors dafür mißbrauchen würde und keinen Serverdaemon dazwischenschalten. Die Vorteile, lägen darin, dass man über dieses Protokoll an den Arduino direkt aus FHEM heraus dem Arduino sagen könnte, auf welchen Kanal er senden soll (das ist wohl das, was Hendryks Serverscript auch macht). Darüber wäre es dann wohl auch möglich
- empfangene Fernbedienungssignale zurück an FHEM an die richtige Adresse zu senden (Man müßte dafür ja nur die Infos, welche FB&welche Gruppe zurückübersetzen)
- das ganze von FHEM aus konfigurierbar zu machen (z.B. dass man die FB/Bridge-ID von FHEM aus vergibt und FB und FHEM-Arduino fpür die Bulbs identisch sind)
Bei Interesse können wir uns dazu mal austauschen.
Zurück zu Deiner Frage: Wird die Bulb eigentlich ausgeschaltet, wenn Du das "off" direkt (ohne FHEM) an den Server gibst? (Ich vermute eher nein, dann müßte man das script mal näher ansehen).
Gruß, Beta-User
Hi Beta-User,
beim Fernziel kommen wir uns sehr Nahe :-) Meine Idee war auch, irgendwann den Umweg über WLAN zu eliminieren und direkt über USB zu gehen. Mich in mysensors einzuarbeiten steht auch noch auf der todo-Liste.
Grundsätzlich funktioniert "off", nur aus FHEM heraus hakt es. Werde mir heute abend das Modul nochmal genauer ansehen: Das dimmt die Birne zuerst und sendet dann das "off" Kommando - möglicherweise verschluckt sich das Skript dabei irgendwie...
Schönes WE,
Oli
Im Modul gibt es eine Ramp, die vielleicht mal auf 0 stellen könnte helfen, wenn es an der Interaktion zwischen dem Script und FHEM hakt.
Ob das mit Ramp auch bei der "MySensors"-Lösung ginge, weiß ich aber nicht, hat mich bisher nicht beschäftigt...
Ebenfalls ein schönes WE,
Beta-User
Hi,
Hat mich Stunden gekostet, aber das Problem war ziemlich trivial :-[ Ich hate mitt default-Einstellungen (Device ID B01234) rumprobiert... Meine RGBWs wollen aber B8xxxx haben, um vernünftig zu funktionieren ::)
Ich bin mittlerweile ein Stück weiter... Mit Hilfe einer modifizieren 30_MilightBridge kann ich nun meine Milights direkt über USB ansteuern. Das ist noch ziemlich unschön, mit hart kodierter Device ID usw..., aber meine erste Erfahrung mit DevIO :-) Wenn ich's rund habe, kann ich es ja evtl. mal hochladen...
Grüße,
Oli
Habe die beta-Version mal hier gepostet (https://forum.fhem.de/index.php/topic,68515.msg599838.html#msg599838) falls es jemanden interessiert ;-)