Milight Hub

[Beta-User]

Nee glaub nicht den Fehler gefunden zu haben...denn wenn ich _2 _3 drücke kommt erst auch wieder diese Abfragen.

Aha, ist auch klar, die readingList der bulb sieht auch "komisch" aus...

Aus dem Wiki (Fußnote für "default"-Einstellungen):

Diese sind:
milight/:device_id/:device_type/:group_id für "topic pattern"
milight/updates/:hex_device_id/:device_type/:group_id für "update topic pattern"
milight/states/:hex_device_id/:device_type/:group_id für "state topic pattern".

Paßt das zu der Abfrage im Dialogfeld...?!?
=> Deine Einstellungen sind immer noch abweichend zum Wiki => Laune beim Helfer kaputt...

ich müsste ja wenn alles jetzt korrekt verbunden wäre auch im webif des hubs unter meiner IP (siehe Bild) wenn ich zb. den Slider ON/OFF bewege die bulb schalten können richtig? udn das tut es noch nicht

RTFM zu den Bulbs...
Wie soll FHEM die schalten können, wenn es der Hub nicht kann...?!? Und wie deutlich muss man es schreiben, dass diese unnötige Rückfrage nicht kommt?

Bin erst mal raus, muß mich erst beruhigen.

[Heisemer Bub]

O.K. Danke Dir für den bis jetzt hilfreichen Thread.

....dann beruhige Dich mal

ich bin dann auch mal raus und der Thread hier kann geschlossen werden.

Viel Grüße

[Beta-User]

Wenn du ihn geschlossen haben willst, kannst du das selbst machen, das ist hier nur nicht üblich, man macht ggf. nur ein [gelöst] oder ähnliches an den Titel im ersten Beitrag.

Da du anscheinend ja nur ein Leuchtmittel hast und wohl weder eine Bedienungs-Anleitung noch eine Fernbedienung oder einen Original-Hub:

Die Dinger sind "dumm" und immer wieder kurz nach dem Einschalten der Stromzufuhr "paarungsbereit". In dieser kurzen Phase muss man (eigentlich) einen Pair-Befehl absetzen (de facto: es funktioniert so ziemlich jedes Kommando an die Dinger, für Fernbedienungen ist der "on"-Knopf üblich), dann blinken die kurz rum und das sollte es gewesen sein...

Siehe z.b. https://www.youtube.com/watch?v=0vN65VqHVSc

(mir bekannte) Probleme:
- es wird "alles mögliche" eingefangen, und bei älteren kann es dann sein, dass die irgendwann keine Lust mehr haben, sich zu paaren (Speicher voll?). Dann muss man die resetten, was afaik nur mit einer FB geht (Dauerdrücken, bis die anfangen schnell zu blinken?); vielleicht geht es auch mit vielen schnellen "unpair"-Kommandos? Keine Ahnung, ich habe für Notfälle (und für die Bedienung von Rollläden via FHEM) noch ein paar FB's rumliegen, die meisten Bulbs sind zwischenzeitlich ZigBee-Leuchtmitteln gewichen...
(OT: ein Leuchtmittel kann durchaus mit mehreren Fernbedienungen (oder Hubs) gepairt sein, wie viele zulässig wären, entzieht sich meiner Kenntnis).
- Das Protokoll muss passen. Es gibt mind. 2 Versionen, der Sidoh-Hub kann beide, aber die Leuchtmittel jeweils nur eins...
- manche Hersteller haben eigene Implementierungen des MiLight-Protokolls (u.a. hier unter Koch? zu finden). Dann kann man vermutlich diese Bulbs gar nicht pairen. Du müßtest also ggf. Infos liefern, was du konkret daliegen hast.

- Manchmal hatten wir schon Verdrahtungsfehler/unpassende GPIO-Zuordnungen. Dann läßt sich der nRF nicht ansteuern.

- zu guter Letzt gibt es viele nRF-Klone, v.a. bei den "kleinen" Platinen. Die funktionieren auch mehr oder weniger gut, berüchtigt sind die "blob"-Versionen mit einem runden Kleberpunkt über dem "nRF"-Chip...

[Heisemer Bub]

Muss den Thread nochmal öffnen!

nach langer Probiererei hab ichs nun geschafft die bulb über die sidoh bridge zu steuern. Soweit so gut!

Was aber immer noch nicht funktioniert ist das ich die bulb aber nicht über Fhem steuern kann

Wenn ich über die sidoh bridge schalte dann wird der Zustand in Fhem auch mit bissl verzögerung geändert zb von State on auf off und umgekehrt....
Auch wenn ich die Farbe über die bridge ändere wird in Fhem der Zeitstempel rot.

Wenn ich das aber in Fhem mache, passiert nothing

list von der sidoh bridge aktuell:

Code Auswählen Erweitern

Internals:
   CFGFN     
   CID        milight_hub_1600842
   DEF        milight_hub_1600842
   FUUID      62d158b4-f33f-b652-3f3e-11f8fd42030288f6
   IODev      MQTT2
   LASTInputDev MQTT2
   MQTT2_CONN MQTT2_192.168.200.167_49153
   MQTT2_MSGCNT 27
   MQTT2_TIME 2022-07-19 15:47:55
   MSGCNT     27
   NAME       MQTT2_milight_hub_1600842
   NR         156
   STATE      <a href="http://192.168.200.167" target="_blank">
connected
</a>Version:
1.10.8
   TYPE       MQTT2_DEVICE
   eventCount 33
   OLDREADINGS:
   READINGS:
     2022-07-15 14:55:30   attrTemplateVersion 20200701
     2022-07-19 15:47:55   firmware        milight-hub
     2022-07-19 15:47:55   ip_address      192.168.200.167
     2022-07-19 15:47:55   reset_reason    External System
     2022-07-19 15:47:55   status          connected
     2022-07-19 15:47:55   version         1.10.8
   hmccu:
Attributes:
   autocreate 1
   bridgeRegexp milight/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
   devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
   icon       mqtt
   model      esp_milight_hub_bridge
   readingList milight/LWT:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setStateList on off
   stateFormat <a href="http://ip_address" target="_blank">
status
</a>Version:
version

list von der bulb:

Code Auswählen Erweitern

Internals:
   CFGFN     
   CID        milight_0xABCD_1
   DEF        milight_0xABCD_1
   FUUID      62d15f13-f33f-b652-d274-0be73fe550e50a2b
   IODev      MQTT2
   LASTInputDev MQTT2
   MQTT2_CONN MQTT2_192.168.200.167_49153
   MQTT2_MSGCNT 224
   MQTT2_TIME 2022-07-19 15:55:11
   MSGCNT     224
   NAME       Essen_OG
   NR         197
   STATE      ON
   TYPE       MQTT2_DEVICE
   eventCount 263
   OLDREADINGS:
   READINGS:
     2022-07-15 14:35:31   IODev           MQTT2
     2022-07-15 15:09:38   associatedWith  MQTT2_milight_hub_1600842
     2022-07-15 15:08:33   attrTemplateVersion 20200522 or prior
     2022-07-19 15:55:11   brightness      0
     2022-07-19 15:55:11   bulb_mode       white
     2022-07-19 15:55:11   color_b         255
     2022-07-19 15:55:11   color_g         255
     2022-07-19 15:55:11   color_r         255
     2022-07-19 08:49:31   command         set_white
     2022-07-19 15:55:11   hex             FFFFFF
     2022-07-19 15:55:11   hue             0
     2022-07-19 15:55:11   state           ON
   hmccu:
Attributes:
   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/
   homebridgeMapping Brightness=brightness::brightness,maxValue=100,factor=0.39216,delay=true
   icon       light_control
   model      esp_milight_hub_rgbw_bulb
   readingList milight/states/0xABCD/rgb_cct/1:.* { json2nameValue($EVENT) }
  milight/states/0xABCD/rgb_cct/0:.* { json2nameValue($EVENT) }
  milight/updates/0xABCD/rgb_cct/1:.* { json2nameValue($EVENT) }
  milight/updates/0xABCD/rgb_cct/0:.* { json2nameValue($EVENT) }
milight/updates/0xABCD/rgbw/1:.* { json2nameValue($EVENT) }
milight/states/0xABCD/rgbw/1:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setExtensionsEvent 1
   setList    on:noArg milight/0xABCD/rgb_cct/1 {"status":"ON"}
  on_transition:slider,3,10,3600 milight/0xABCD/rgb_cct/1 {"status":"ON","transition":$EVTPART1}
  off:noArg milight/0xABCD/rgb_cct/1 {"status":"OFF"}
  off_transition:slider,3,10,3600 milight/0xABCD/rgb_cct/1 {"status":"OFF","transition":$EVTPART1}
  brightness:colorpicker,BRI,0,15,255 milight/0xABCD/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
  hue:colorpicker,HUE,0,1,359 milight/0xABCD/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
  command:uzsuSelectRadio,Weiss,Nacht milight/0xABCD/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

Ich denke das ich irgendwas noch übersehe, aber ich sehe den Wald vor lauter Bäume nicht.

Über ne Info was Euch ev. noch auffällt bedanke ich mich.

P.S. Ich habe keine Fernbedienung....nur die sidoh bridge und die bulb

[Beta-User]

Ist das nun eine cct-Type oder eine rgbw?

Du hast in der readingList beides (vermutlich von erfolglosen Versuchen), und von daher hat das attrTemplate dann (vermutlich) "das erstbeste passende" in die setList übertragen....

Ergo: Finde raus, wie die am Hub geschaltet werden kann, lösche dann das Device wieder, schalte am Hub und wende dann das passende attrTemplate an (auf das neu automatisch erstellte Device). (Oder mache es manuell, dass du die richtigen set-Topics reinnimmst).

[Heisemer Bub]

in der sidoh bridge war rechts oben immer rgbw-cct udn mit dem gings net...bis ich draufgekommen bin das man da auf rgbw stellen muss...dann konnte ich schalten aber wie gesagt nur von der bridge aus....

O.K. ich werde die bulb nochmal komplett löschen udn dann an der bridge schauen das da rgbw ausgewählt ist....dann da bissl schalten über bridge ....dann wird ja über autocreate wieder eine neue bulb erstellt......und dann das template auswählen. hier wäre jetzt noch meine frage welches template dann genau auzuwählen ist?

wäre dann das esp_milight_hub__rgbw_bulb template richtig? möchte nur auf nummer sicher gehen.....

Gruss

[Heisemer Bub]

Hi beta-user,

so jetzt hats auch geklappt......so gemacht wie du gewschrieben hast und auch so die Schritte durchgeführt.... passt jetzt geht der Slider in Fhem Top danke Dir

habe nochmal auch für andere eventuell noch die Schritte per Bild hier angelegt....

Frage noch schau dir mal die Birne an in Fhem...da feheln doch die striche außenherum....ist das ein Ubertragungsfehler noch??

Ansonsten mit dem Alexa namen kann ich jetzt auch über >Alexa noch steuern richtig?

dann nochmals danke für die geduld und HIlfe.

Gruss

[Heisemer Bub]

Witzig...war jetzt voll euphorisch udn habe dann natürlich eine zweite (genau die gleihe LED) eingebunden - natürlich hat es mit dieser nicht funktioniert

habe als ID die 0xABCE gewählt auch RGBW und Gruppe 1 (habe auch die Gruppe 2 probiert)...dann über die sidoh bridge geschaltet ...wurde auch wieder ein Device angelegt....wieder bei der ID "milight" eingegeben....und alexa name......

dann geschaltet und nix tut sich..gibts doch nicht...genauso angelegt.......

Anmerkung: UDP Ports in der sidoh bridge sind keine vergeben!

list des zweiten devices:

Code Auswählen Erweitern

Internals:
   CFGFN     
   CID        milight_0xABCE_2
   DEF        milight_0xABCE_2
   FUUID      62d70ae6-f33f-b652-f782-e03660395df6cfb9
   IODev      MQTT2
   LASTInputDev MQTT2
   MQTT2_CONN MQTT2_192.168.200.167_49169
   MQTT2_MSGCNT 43
   MQTT2_TIME 2022-07-19 21:53:45
   MSGCNT     43
   NAME       Fitnessstudio
   NR         2628
   STATE      OFF
   TYPE       MQTT2_DEVICE
   eventCount 51
   OLDREADINGS:
   READINGS:
     2022-07-19 21:49:58   IODev           MQTT2
     2022-07-19 21:49:59   associatedWith  MQTT2_milight_hub_1600842
     2022-07-19 21:50:26   attrTemplateVersion 20200522 or prior
     2022-07-19 21:53:45   bulb_mode       color
     2022-07-19 21:53:45   color_b         0
     2022-07-19 21:53:45   color_g         255
     2022-07-19 21:53:45   color_r         33
     2022-07-19 21:53:45   hex             21FF00
     2022-07-19 21:53:38   hue             112
     2022-07-19 21:53:45   state           OFF
   hmccu:
Attributes:
   alexaName  Fitnessstudio
   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/0xABCE/rgbw/2:.* { json2nameValue($EVENT) }
  milight/states/0xABCE/rgbw/0:.* { json2nameValue($EVENT) }
  milight/updates/0xABCE/rgbw/2:.* { json2nameValue($EVENT) }
  milight/updates/0xABCE/rgbw/0:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setExtensionsEvent 1
   setList    on:noArg milight/0xABCE/rgbw/2 {"status":"ON"}
  on_transition:slider,3,10,3600 milight/0xABCE/rgbw/2 {"status":"ON","transition":$EVTPART1}
  off:noArg milight/0xABCE/rgbw/2 {"status":"OFF"}
  off_transition:slider,3,10,3600 milight/0xABCE/rgbw/2 {"status":"OFF","transition":$EVTPART1}
  brightness:colorpicker,BRI,0,15,255 milight/0xABCE/rgbw/2 {"$EVTPART0":"$EVTPART1"}
  hue:colorpicker,HUE,0,1,359 milight/0xABCE/rgbw/2 {"$EVTPART0":"$EVTPART1"}
  command:uzsuSelectRadio,Weiss,Nacht milight/0xABCE/rgbw/2 {"$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

[Beta-User]

Hmmm, eigentlich sollte die Abfrage nach BASE_ID ("milight") gar nicht kommen, schaue ich mir ggf. mal an.

Warum sich die 2. Bulb anscheinend nur über den Hub schalten läßt? Keine Ahnung... Hat jedenfalls mit UDP nichts zu tun, MQTT ist was völlig anderes. Jedenfalls macht der MQTT-Weg auch nichts wesentlich anderes als eine Anweisung über das HTTP-Web-Interface, nämlich: Sende irgendein bestimmtes MiLight-kompatibles Funksignal raus. Warum das mal empfangen (und umgesetzt) wird und mal nicht kann von vielen Faktoren abhängen. Falls du die zwischenzeitlich eingebaut hast, würde ich die Änderung der Funkstrecke verantwortlich machen, aber dazu schreibst du nichts...

Übrigens: Wenn die dieselbe Gruppenkennung haben, kann man sie auch über den Gruppenbefehl miteinander ein- und ausschalten (nur falls das ggf. eigentlich gewollt ist). Dann wäre nur eine andere Endnummer des Kanals zu wählen (also die eine auf "1", die nächste auf "2" (vermutlich bis rgbw max. "4", bzw. die CCT-Varianten mind. .

[Heisemer Bub]

Hmmm, eigentlich sollte die Abfrage nach BASE_ID ("milight") gar nicht kommen, schaue ich mir ggf. mal an.

Wäre supernett von Dir

Warum sich die 2. Bulb anscheinend nur über den Hub schalten läßt? Keine Ahnung... Hat jedenfalls mit UDP nichts zu tun, MQTT ist was völlig anderes.

Nee, dann habe ich mich falsch ausgedrückt...die 2. Bulb kann ich weder über die sidoh bridge noch über fhem steuern.
O.K. die ports in der sidoh bridge bei UDP habe ich auch gelöscht...da MQTT wie Du schon sagst was eigenständiges ist.

Warum das mal empfangen (und umgesetzt) wird und mal nicht kann von vielen Faktoren abhängen. Falls du die zwischenzeitlich eingebaut hast, würde ich die Änderung der Funkstrecke verantwortlich machen, aber dazu schreibst du nichts...

Sorry..aber ich habe auch schon daran gedacht und habe dann mal die sidoh bridge näher zur zweiten Bulb gesetzt....auch dann klappts nicht....wenn ich dann wieder in der sidoh brisge auf die 1. bulb stelle dann kann ich vom Keller (1.Bulb ist im OG) aus die 1. Bulb steuern und auch in Fhem...komisch und krass.

Also liegts ja nicht an der Entfernung.....

Ich denke das hat irgendwas mit den "Internals" zu tun, aber da ist mein Wissen nicht gut genug..aber das vermute ich!

Gruss und Danke

[Beta-User]

Wenn du die Bulb nicht über die sidoh-Bridge direkt ansteuern kannst, brauchst du in FHEM gar nicht erst zu suchen. Das ist immer VORAUSGESETZT!

Zum Pairing hatte ich doch schon ausgiebig geschrieben?!? Schon vergessen?

Und anschauen: Ja, vielleicht, eilt aber ja nicht. Da das mit der anderen Bulb klappt, ist das hier ja nicht das Thema mit der BASE_ID, Hautpsache am Ende steht das richtige im Device...

[Heisemer Bub]

Zum Pairing hatte ich doch schon ausgiebig geschrieben?!? Schon vergessen?

nee nicht vergessen....die erste habe ich ja auch so eingebunden...also sollte es bei der 2. auch funktionieren....tuts aber nicht....schaue und probiere weiter....