The light was just blinking with whatever the last colour the light was on before.
This works though, it now blinks in red colour !
I’ve hit a problem seem it doesn’t work to turn on and set a colour for all Hue lights ?
The one I want to set to blue “Cabinet Light Strip” is a genuine Philips Hue V1 LED light strip.
The one I am setting to red (this one works) is a 3rd party Dresden FLS-PP ballast / LED light strip.
For the “Cabinet Light Strip” it seems it cannot turn on and then change the colour to blue, it just turns on and remains on whatever the last colour was (green in my test)
If I already have the “Cabinet Light Strip” turned on and then run the rule, it does change its colour to blue.
The other Dresden one “TV Backlight” works fine, say I set that to green and then turn it off.
If I then run this rule it does turn on and changes to red.
So not sure why this is?
MSR can also send this “alert” command in an action to the Ezlo Hue plugin.
Tested it and it does work !
For the alert, use the x_ezlo_device.set_item_value action with the item name and desired value:
I have the same problem in an MSR rule as I did with the Meshbot rule for that gen 1 Philips Hue LED strip light.
It blinks with the alert command OK, but it does not then change colour to the desired colour (blue) and just remains on whatever its last colour was.
So seems to be a limitation with this particular Hue light for some reason, when this light is OFF to begin with.
However if the light is already ON, then it works, it blinks and the colour changes to the set colour (blue).
Yet the none Philips Hue light the 3rd party Dresden one works fine and blinks and changes colour to my desired colour, so go figure !
EDIT: Just tested with a Philips Hue RGBW light bulb and its the same as the Philips Hue LED strip. If the light was off to begin with, it blinks OK but does not change to the desired set colour.
Curious why 3rd party lights seem to work OK but the Philips ones dont.
I’ve now setup a motion sensor in the hallway with a meshbot to control a hue light in there. However, the total delay between the motion sensor triggering and the light turning on is just too long. Right now it’s about 4 seconds, this really should be less than 1 second to be useful.
Are there any planned optimisations to improve performance of the hue plugin?
hello @jouked
Are you getting this delay in Cloud or Local meshbot?
I cannot check this through the UI, but it should be local, I’ve never tried a cloud meshbot so far. I do have similar motion sensor/light setups using z-wave lights, they work much more rapidly. So I suspect the hue plugin to be the cause of the delay.
Manual control of the hue light through the vera app also has a similar delay. Using the hue app, reaction is instant.
@jouked Ticket for the issue you reported has been created. You can track ticket’s status using this link Service Desk
Has anyone added a new light to their Philips Hue Bridge whilst having this Ezlo Hue plugin already installed?
I’d be interested to hear of your experience, did it just add one new light device OK into the Ezlo devices list ?
Thanks.
hi @jouked
wi-fi and zigbee broadcasts are made from similar channels cause, you can change the zigbee channel through the hue application and uninstalled the plugin from your controller and reinstalled it.
After this process, we also tested it with the motion sensor and we did not see a problem.
I carefully checked my wifi and zigbee setup and the fix you propose is really not applicable to my setup. My home wifi channel is far away from the zigbee channel. Furthermore, if there would be interference between the two, I’d witness similar delays using the native Hue app on the same phone. This is not the case, it’s really a local delay within the Ezlo stack.
Hopefully you can find another hypotheses for this issue.
Hello @jouked
Please keep in mind, that your WiFi network is not the only signal around, any other WiFi network or wireless signal can interfere with your ZigBee network.
Also, you can use different freeware to scan your environment and know the channels of the networks around.
Anyway, we will check the issue deeply.
Please give it a try and let us know your results, we will be attentive.
Hi @jouked ,
On our side we investigated the issue also on code level and let me show you what happens on Ezlo stack
So as a summary:
user clicks on the UI : 16:29:26.901408
Plugin scripts start executing : 16:29:26.987219
HTTP request sent to Hue Bridge : 16:29:27.010026
Response from Hue Bridge : 16:29:33.557941
So it seems it’s NOT on Ezlo stack. Thats why we come up with other hypothesis.
We will continue to investigate the issue and let you know if we can find the error on the Hue Bridge.
From that logging there seems to be no delay for sure. I tried capturing network traffic to inspect the delay between sending a command from the Vera App to the hub, and the hub informing the hue bridge. However, it’s pretty hard to capture this fully, the Vera App communication is probably all relayed through Google Cloud?
Can I enable the debug mode on my hub to capture the same logs that you show? Ideally capturing the motion sensor trigger and meshbot execution as well.
the communication to Hue Bridge is not going through cloud. It sends the request directly via local IP.
So you should be able to get the same logs from your hub.
The bit from hub to bridge is indeed easy to spot. In this screenshot, 192.168.100.25 is the Ezlo hub, 192.168.100.42 is the hue bridge. So clearly the moment the command is send is visible, trouble here is to match it to an action in the Vera App. That’s probably the interaction between the Ezlo hub and 35.247.112.170 just above, but that’s just an assumption on my side.
In the Vera mobile app in Settings Customer Care at the bottom of that page it says Connection Status.
It can be either locally connected or relay connected (cloud).
Ideally it should say locally connected when at home.
Also what type of motion sensor is it? And is it paired to the Ezlo hub or paired on the Hue Bridge hub?
Ok, brilliant, that’s a lot easier to capture than. New example:
192.168.100.85 → 192.168.100.25 is vera app to Ezlo hub communication
192.168.100.25 → 192.168.100.42 is Ezlo hub to Hue bridge communication
The capture is not prefect (I think the capture functionality within my home router does not capture an absolute 100% of traffic), but you can witness the delays happening already:
Packet 31-44: 2 second delay
Packet 52-112: delay is such that the light is not triggered. This was me flipping the switch several times in the app, without the light reacting to the input.
Packet 337-347: Again a 2 second delay
So, not a perfect capture, but some indication on delays happing in my Ezlo hub setup. It would be interesting to get some extra logging on the hub itself to see the sequence of events within the hub.
The PIR is a neo coolcam Z-wave device, controlled from the Ezlo hub.
Oh, and just FYI, I’m using the exact same motion sensor, with a Meshbot, to directly control a z-wave light in a different room. That setup works much more responsive and the variation in delay between sensing motion and triggering the light is much more stable.
The hue light has a much larger variance in reacting.
I think the Ezlo Philips HUE plugin is currently broken or has a major bug in it.
I ended up in a situation where the plugin kept generating new instances of all my Hue devices onto the Ezlo hub over and over and I ended up with 1000’s of device instances on my system and it ground it to a halt.
Support had to remove the plugin and all the devices via a script or something.
I have not been brave enough to install their Hue plugin again since. The bad version is 1.0.17 and that is the one still on the marketplace.
So currently my Ezlo Plus controller cannot directly control my Philips Hue lights.
A work around is that I am using Rene’s Vera to Ezlo bridge plugin and the AltHue plugin devices on the Vera Plus are being exposed to the Ezlo Plus that way instead.
Any news on a new plugin version with bug fix ?
Thanks.