I did a little more research: when the EspMilightHub binding is started normally with openhab it begins with initialization of milight things and receiving all retained state messages. All messages are processed. After a short while I see a disconnect in the broker log:
1537258867: Received DISCONNECT from espMilightHub:001
1537258867: No will message specified.
1537258867: Sending CONNACK to espMilightHub:001 (1, 0)
1537258868: Received SUBSCRIBE from espMilightHub:001
1537258868: milight/states/# (QoS 1)
1537258868: espMilightHub:001 1 milight/states/#
1537258868: Sending SUBACK to espMilightHub:001
1537258868: Sending PUBLISH to espMilightHub:001 (d0, q0, r1, m0, āmilight/states/0x7785/fut089/1ā, ā¦ (62 bytes))
1537258868: Sending PUBLISH to espMilightHub:001 (d0, q0, r1, m0, āmilight/states/0x7785/fut089/8ā, ā¦ (34 bytes))
When I force to restart the mosquitto broker I can see the connections coming up but I donāt see a disconnect and the connection is vivid.
So for me it looks like a special case in the EspMilightHub binding.
Is the sonoff bridge compatible with the milight? What RF chip sits inside the bridge? It comes soldered and inside a nice case, and it can easily be flashed with custom software, so I was thinking maybe this device could be used as the miilight hub, instead of soldering some components together.
No
The rf in the sonoff is 433mhz.
Not compatible with the milights.
You will need to follow the bridge instructions.
It works very well
No need for soldering. Jumper wires are fine.
@joga
Yes the binding does connect, disconnect a moment later and then re-connect a second time, I forget why just right now. Possibly it was to do with fetching the retained messages only on startup and not if there was a minor network issue that caused a short drop out.
Maybe the issue is to do with your broker is still busy with the disconnect when the second connection request is made. How fast is the machine that is running the broker?
@matt1 it is a limited hardware, a RPi2. Usually it is more than sufficient but that issue might be due to the lack of performance. And you are right, the disconnect occurs after fetching the retained messages. Can you add a feature that assures the vivid connection to the broker? That would be the best solution in my view.
Iām trying to get this to work, but I donāt understand something. You mention that the binding is standalone (āYou do not need to have any mqtt bindings installed as this binding is fully standaloneā) but also that āYou then need to get MQTT running as this method uses the faster and lightweight MQTT protcol and not UDP.ā Which of these is true?
Also, is there some URI with the jar file so I can conveniently wget it on my linux machine? Right now I need SCP into it and thatās difficult with all kinds of permission issues. Still canāt get it to workā¦
Also when does this binding become an official one?
Gabri both are true dependING on your point of view. You need to setup what is called a mqtt broker somewhere on your network. Google what a broker is and if u use openhabian look at mosquitto.
If you use openhabian you can use the samba share to send the binding over the network. You can use wget and then unzip the file. Due to most antivirus complaining about jar files I wonāt provide an unzipped version.
This binding probably never will become official as an official one already exists and having two would be confusing. If I ever get spare time I may add this to the market place, it is up on github and fully opensource.
Hello, thank you so much for your effort matt1. The binding works like a charme and my wife loves it. Now as i am missing her usual bleating i want to enable the disco mode
Is there a way todirectly switch to e.g. Mode 3 in a rule?
Do i have to go the mqtt binding way to send a command like that or can i hand out the {āmodeā:ā3ā} somehow to your binding to let it do the job?
Doing it through your binding would be cool cause it already has a fifo and tuned delays to accomplish the tasks
Been a long time since I wrote the code but there is a channel for doing that. Called ādiscomodeā Should be as simple as sending it the number you want with the rule.
From the source codeā¦
<channel-type id="discomode">
<item-type>Number</item-type>
<label>Disco mode</label>
<description>Switch to a Disco mode directly by using the number. Not supported by all globe types.</description>
<state>
<options>
<option value="0">Disco 0</option>
<option value="1">Disco 1</option>
<option value="2">Disco 2</option>
<option value="3">Disco 3</option>
<option value="4">Disco 4</option>
<option value="5">Disco 5</option>
<option value="6">Disco 6</option>
<option value="7">Disco 7</option>
<option value="8">Disco 8</option>
</options>
</state>
</channel-type>
Hi playing with DiyHue hub which is talking to ESPmilightHub over REST API. Trying with Original Philips Hue app and other music sync and mood apps like Hue Disco, Hue Manic.
It works but problem is, that after little while the ESPbridge get overloaded and stop responding (even for ping).
I played with RF setting, but not much different. Any experience with this? What part of ESPMilightHug get overloaded with REST API requests Any HW improovement possible?
Its not just about delay but about killing the Bridge with lot of requests ā¦
Switch Remote_0_State "Light On/Off" {channel="espmilighthub:rgb_cct:001:0x5D8C0:level"}
Dimmer Remote_0_Level "Remote" {channel="espmilighthub:rgb_cct:001:0x5D8C0:level"}
Dimmer Remote_0_CTemp "White Color Temp" {channel="espmilighthub:rgb_cct:001:0x5D8C0:colourtemperature"}
Color Remote_0_Hue "Remote" {channel="espmilighthub:rgb_cct:001:0x5D8C0:colour"}
String Remote_0_Cmd "Command to Send" {channel="espmilighthub:rgb_cct:001:0x5D8C0:bulbcommand"}
Switch Remote_0_SndCmd "Send Command" {channel="espmilighthub:rgb_cct:001:0x5D8C0:sendbulbcommand"}
Number Remote_0_Mode "Set Discomode" {channel="espmilighthub:rgb_cct:001:0x5D8C0:discomode"}
Switch Remote_1_State "Light On/Off" {channel="espmilighthub:rgb_cct:001:0x5D8C1:level"}
Dimmer Remote_1_Level "Remote" {channel="espmilighthub:rgb_cct:001:0x5D8C1:level"}
Dimmer Remote_1_CTemp "White Color Temp" {channel="espmilighthub:rgb_cct:001:0x5D8C1:colourtemperature"}
Color Remote_1_Hue "Remote" {channel="espmilighthub:rgb_cct:001:0x5D8C1:colour"}
String Remote_1_Cmd "Command to Send" {channel="espmilighthub:rgb_cct:001:0x5D8C1:bulbcommand"}
Switch Remote_1_SndCmd "Send Command" {channel="espmilighthub:rgb_cct:001:0x5D8C1:sendbulbcommand"}
Number Remote_1_Mode "Set Discomode" {channel="espmilighthub:rgb_cct:001:0x5D8C1:discomode"}
Switch Remote_2_State "Light On/Off" {channel="espmilighthub:rgb_cct:001:0x5D8C2:level"}
Dimmer Remote_2_Level "Remote" {channel="espmilighthub:rgb_cct:001:0x5D8C2:level"}
Dimmer Remote_2_CTemp "White Color Temp" {channel="espmilighthub:rgb_cct:001:0x5D8C2:colourtemperature"}
Color Remote_2_Hue "Remote" {channel="espmilighthub:rgb_cct:001:0x5D8C2:colour"}
String Remote_2_Cmd "Command to Send" {channel="espmilighthub:rgb_cct:001:0x5D8C2:bulbcommand"}
Switch Remote_2_SndCmd "Send Command" {channel="espmilighthub:rgb_cct:001:0x5D8C2:sendbulbcommand"}
Number Remote_2_Mode "Set Discomode" {channel="espmilighthub:rgb_cct:001:0x5D8C2:discomode"}
Switch Remote_3_State "Light On/Off" {channel="espmilighthub:rgb_cct:001:0x5D8C3:level"}
Dimmer Remote_3_Level "Remote" {channel="espmilighthub:rgb_cct:001:0x5D8C3:level"}
Dimmer Remote_3_CTemp "White Color Temp" {channel="espmilighthub:rgb_cct:001:0x5D8C3:colourtemperature"}
Color Remote_3_Hue "Remote" {channel="espmilighthub:rgb_cct:001:0x5D8C3:colour"}
String Remote_3_Cmd "Command to Send" {channel="espmilighthub:rgb_cct:001:0x5D8C3:bulbcommand"}
Switch Remote_3_SndCmd "Send Command" {channel="espmilighthub:rgb_cct:001:0x5D8C3:sendbulbcommand"}
Number Remote_3_Mode "Set Discomode" {channel="espmilighthub:rgb_cct:001:0x5D8C3:discomode"}
Switch Remote_4_State "Light On/Off" {channel="espmilighthub:rgb_cct:001:0x5D8C4:level"}
Dimmer Remote_4_Level "Remote" {channel="espmilighthub:rgb_cct:001:0x5D8C4:level"}
Dimmer Remote_4_CTemp "White Color Temp" {channel="espmilighthub:rgb_cct:001:0x5D8C4:colourtemperature"}
Color Remote_4_Hue "Remote" {channel="espmilighthub:rgb_cct:001:0x5D8C4:colour"}
String Remote_4_Cmd "Command to Send" {channel="espmilighthub:rgb_cct:001:0x5D8C4:bulbcommand"}
Switch Remote_4_SndCmd "Send Command" {channel="espmilighthub:rgb_cct:001:0x5D8C4:sendbulbcommand"}
Number Remote_4_Mode "Set Discomode" {channel="espmilighthub:rgb_cct:001:0x5D8C4:discomode"}
Now, when i press a button on the remote i get this for exampel from mqttt: milight/states/0x5D8C/rgb_cct/1 {"state":"ON","level":1,"hue":216,"saturation":98,"bulb_mode":"color"}
If i understood it correctly the "virtual " bulb should now update its state. But my rule doesnĀ“t trigger:
rule "Remote"
when
Item Remote_1_State received command //received update also doesnĀ“t work
then
Kuechenlicht_0_State.sendCommand(Remote_1_State.state.toString)
end
I also donĀ“t see anything in the karaf console. But if i change the state of Milight_1 in paper ui the rule triggers and works as expected.
Is this the wrong approach to use a remote with your binding? Or isnĀ“t it possible at all?
@Sledgeha1
Incoming MQTT does not trigger a ācommandā instead it does an āupdateā. This is to stop feedback loops, hopefully just update the rule to react to updates and not commands and it should start working. If you watch the event.log you can then see what happens on the event bus and adjust your rules to suit.
Any HW improovement possible? 