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

Begonnen von schka17, 09 Oktober 2016, 16:33:55

Vorheriges Thema - Nächstes Thema

FLOK

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


Markus.

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

projectsun

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?
Zentrale Ubuntu, Rpi B+ mit Busware 868 CUL ser2net, Rpi 2 an Aquarium mit DS18B20, und S0Counter, Rpi 3 mit nanoCUL 433 und 868 ser2net, 7x Revolt NC-5462, 1x miniCUL WLAN, 3x IT-1000, 6x ELRO AB440, KS300, EM1000-HSM, EM1000-WZ, FHT80B, 5x FHT8v2, 20x Nodemcu mit Sensoren, 6x Echo, Sonos

Beta-User

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 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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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, 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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Kurzer Update: Die MQTT-Implementierung läuft - zumindest auf den ersten Blick - jetzt super!

Details hier, über Unterstützung bei den "Restarbeiten" würde ich mich sehr freuen ;D .

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

Markus.


Beta-User

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Markus.

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

Fhemerle

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

anoll

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
und zwei GU5.3 Strahler 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

Beta-User

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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

herrmannj

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


Beta-User

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Markus.

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