If i create a group in Phoscon, the group comes available over the API. Then i can send a Scene to that group.
Even so, In home assistant the group exposes as 1 light. If i put it behind a color wheel, it sends the colors to the group as it being a light. That works flawlessly.
Thanks, and that is correct but it is still a group, or is it my mistake?
I need different colors to set into single lamps because there are huge color differences between these YNOA gu10 spots.
i do not use home assistant… only domoticz.
i can make scenes in domoticz, but then it seems the api (limit) is getting overload, and so i have to use another way to do single requests… but how, on an easy way?
i’m do not have enough time to do a lot of scripting to only turn some lights on or off…
there has to be a way to do it simple, or does the phoscon hardware not meet my expectations and do i have to replace my hue gateway again?
grouping in deconz turns on all devices, that is correct, but not 1 by 1 to a dim / color value.
do scenes in deconz, can send out 1 by 1 to the value i need, but then i need to send out 2 or 3x requests before all lamps are on to the value i want (request overload?)
do scenes in domoticz, also need more requests to turn all lights on (api limit ?)
Domoticz can do color changing to a group, but not into scenes.
Then i need to make a scene in deconz itself OR in domoticz, but then i get the api limit troubles or send out more requests then needed…
this is a scene i’m using now:
the groups works correctly, as they are at 1 color, no need to change.
the scenes does not working correctly, need to send out 2 or 3 times the request before all scenes are correctly dimmed or has the colors i want in that scene.
deconz groups:
It can, I have already do it. And it make only 1 API request by scene, all values are in the same request (state/color/level).
But on your capture, the 5th is a scene with color ? (LEDStripBinnen) so it’s possible ?
On phoscon, if you use the " Recall scenes" sections, you still have dimmer not working ?
And bad news, I have take a look on Lua/dzevent code on domoticz, and I think the better solution is using a full custom code …
IDK wich one language you prefer, some are using php, on my side I prefer to use python. But it seem there is no way to delay a command with a delay in milliseconds natively in domoticz.
And the HUE gateway don’t have this request limitation ? So you can use more than 20 requests in 1 seconds ?
This LEDStripBinnen is Milight, not Deconz.
In domoticz, yes, ofcourse i can do dim and make color directly to the devices in the scene, but as seen earlier it gives me the errors about the api limitation / requests and does NOT turning on ALL lamps when the scene in domoticz is activated.
This morning i removed the deconz controller, and give the hue another try to test.
So, i removed and resetted all devices and did a new start on the hue…
After 4 minutes all devices where found and added into the hue and domoticz as well…
Like i said before, its working perfectly without any hitches.
I can switch all devices directly from domoticz in a scene and even the all effect scenes (in hue bridge) are working (like disco).
I do not use these effects, but i just did a test…
Now, i have done exactly the same as i did before in domoticz with the HUE as gateway:
Using HUE Bridge as gateway
making a new scene in domoticz (to test)
set all devices as single in Domoticz (so no groups / scenes from the hue bridge itself)
set dim level AND set color per device
saved the scene
activated the scene NONE problems, none errors
All lights goes on, dim to the value i want and the colors are correctly set in 1 push (so in 1 request)
What suprises me is that when i activate the scene in domoticz, not all lights goes on directly (what deconz did) but goes on one by one (after nearly 1 sec per device) and goes on by fading wich deconz didnt do at some devices…
When activate the scene, it will took 6 till 8 seconds before all lights are on, but they are ALL on AND dimmed into the value i wanted, in 1 request…
I tested this several times, turning all OFF, scene ON again, testing other scene ON, etc… but it works, and it stays working.
So far i’m happy to replace deconz back to the hue bridge. For me it’s way better then before!
But, i really wish to use the deconz again when it’s working like it should do, but it does not atm.
Beside that, a custom script is getting to complex to just turning on an lamp, device, making a scene or change values.
My wife is also living in this house who wants to use the lights / knobs and change some values from inside domoticz. She does not have any scripting languages.
So, if the HUE can do… Why Phoscon not?
“And the HUE gateway don’t have this request limitation ? So you can use more than 20 requests in 1 seconds ?”
I really don’t know the specs in detail or limitations of the HUE bridge, the only thing i know is i can setup 50 devices, after that i need an second HUE Bridge.
*Edit: on a forum someone says: the hue hub can only process twenty different requests per second
i think this is the same as deconz?
It’s possible at the origin the deconz working mode was based on HUE gateway.
So, if the HUE can do… Why Phoscon not?
I think the 2 gateway have a different working mode
The Hue gateway use a internal buffer to delay the request, it s for that you have nearly 1 sec per device)
The deconz gateway send request fastly but as it don’t memorise request, if it can’t send them, it display error, so you need to make the buffer yourself.
Another difference, I can be wrong but on the HUE gateway you can change a color on a bulb in off state, because it memorise request, not possible on deconz because deconz don’t memorise the request and you can’t send it to a off bulb.
Ahaa, now i know why the HUE is better working with a scene then Deconz does then.
Thanks, that explained a lot
I really, really hope that deconz will make a “buffer” to the requests in the future then, so i can use Deconz again!!
I think it has to be possible?
That would make my day
The current handling of such rapid requests in deCONZ doesn’t scale well and clients are basically need to add some delays for their requests (which the Hue bridge likely does internally).
In future deCONZ will handle this differently so that a client can for example set the state for 200 lights without delays and deCONZ will take care of the rest.
The main problem currently is that the code often does “fire and forget” for commands which isn’t very reliable, so in future we will do a record target state, exec commands, check that it actually worked and repeat if not. The approach is roughly described in the following issue:
I understand.
Maybe the devs should make an “option” to use buffering and/or logging of those messages/requests so we can choose by ourself to use 1 request per second or not… That would do the job i guess!
Ahh! That is great to hear!! Now i know our problem in here then, thanks for answering!
That explains a lot.
G’Luck with programming of this.
I’m happy to see that you guys are taking it seriously.
I tought that the zigbee protocol was made right for “controlling” these devices and its state?!
As we know, most of the 433 mhz devices are just a one-way wich is working fine to turn on or off some lights, but you never know if the target gets his signal and also you cannot check its state like z-wave or zigbee does.
That is exactly the reason why i choose for zigbee and z-wave devices instead of these 433mhz bulbs/switches.
So, the state is correct in Zigbee, but the signal > message is only send out once and when the signal is not recieved by the device the device stays in last state without talking back?
I m not sure to understand what you want to say, but the deconz API “cheat” to be faster.
When you send a request, the value is updated first in the API, then the zigbee request made, and the result is “adjusted” later with zigbee return (with state return or transmition error)
On zigbee side, the request is send more than 1 time.
But ATM as deconz don’t use queue list / buffer this part need to be done on client side to delay request to the API.
To answer your first question, to what question you want more information?
Second: Well, it seems the hue bridge does have this queue list internally (i guess?) and not from outside (plugin in domoticz)?
It does fine for several days now without any faulty signal or problem…
So i really don’t know if the hue does it itself or the plugin in domoticz does this queing.
Good question, the HUE plugin is integrated on domoticz core, so more files to check to be sure, but I think it’s from the HUE gateway.
And just for fun, the first version of the deconz domoticz plugin was using domoticz API fonction for HTTP request and a buffer ^^
look at the fonction SendCommand()
But I have used later direct python fonction like request to make the code faster, and as on local network request was almost immediate (and because for me no one can need to send more than 20 requests in 1s) , I have removed the buffer feature.
No, sorry, was arealy old version. And less problems with using the python library instead of the domoticz build in one.
ATM the easier way I m seing to use it with domoticz, is making domoticz scenes, to make requests easier (it’s easier to trigger a scene using script than making a HTTP request with a JSON and all parameter).
And using script to trigger all scenes one by one with a delay. But the sleep() command is not native in LUA/DZevent.
