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

Markus.

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

FLOK

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

herrmannj


FLOK

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

herrmannj


smoudo

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

herrmannj

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)

FLOK

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

TomLee

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 ?

Markus.

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

Gunther

FHEM@Proxmox@Nuc: TabletUI als User-Interface (4 Wandtablets) / IOs per ser2net gekapselt
Homematic: Heizung, Fenster, Bewegung | Jeelink: Temperatur | Z-Wave: Bewegung, Temperatur | FS20: Temperatur, Fenster | Viessmann-Heizung eingebunden

Beta-User

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

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.

FLOK

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

Markus.

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