-
-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Home Assistant lights #1014
Conversation
@awawa-dev Hello, Have tested Home Assistant implementation. If you have only two lights under Home Assistant and use the wizard, everything is as it should be and user-friendly. After I have determined and saved the position for my two lamps, I find myself in the Lamp(s) overview page again. Now all lamps from Wizard are also here. I have removed the lamps that I don't want, but in the LED visualization and layout preview they appear as top lamps. You can delete them one by one in the context menu under lamp layout, but I think it would be better if I could only select the lamps that I really need in the wizard. Ah yes, all lamps found by the Wizard are also switched on, even if only two lamps are actually used. Otherwise, great work, and thank you for the implementation. |
Have you checked the delays in the logs? If HyperHDR is installed on another unit, then for each lamp each POST command takes about 20ms (if HyperHDR is installed on a unit with HA, then it would be a bit less). So if we have 10 lamps on one instance, then refreshing the instance would take 200ms :-/ You can try to get around this and put each of them on a separate instance, but then Home Assistance will probably freeze or get clogged anyway. Unfortunately, this HA API and the entire Zigbee/MQTT was not designed for streaming colors and the Philips Hue bridge with UDP still beats it hands down. |
@awawa-dev Hello, When I switch off my first instance with HyperSerialPico on the SK6812RGBW and no real Ambilight is available as a comparison, the lamps defined as left and right under Home Assistant look very nice and the small lag no longer bothers you at all.
|
Thank you @satgit62 very much for your tests and comments. I will try to take them into account in the near future. BTW if you have a delay of 40-50ms you can set the transition to 30-40ms then it should work a bit smoother. |
Any chance to get that working with z2m only? |
@schwatter In such a configuration, is z2m connected directly to the mqtt broker like mosquitto? Can you provide a link to an article that describes in detail the each step of configuring such a setup? |
@awawa-dev Hello, 0x04cd15fffe8de6e9 is exactly the Zigbee lamp it wants to control. 2024-12-19T14:09:37.331Z [LEDDEVICE] (ProviderRestApi.cpp:174) POST begin: [turn_on] [{"brightness":18,"entity_id":"0x04cd15fffe8de6e9","rgb_color":[83,0,0]}]2024-12-19T14:09:37.342Z [LEDDEVICE] (ProviderRestApi.cpp:198) POST end (11 ms): [turn_on] [{"brightness":18,"entity_id":"0x04cd15fffe8de6e9","rgb_color":[83,0,0]}]2024-12-19T14:09:37.343Z [LEDDEVICE] Reply error. Reason: [400 Bad Request] - Check Request Body2024-12-19T14:09:37.343Z [LEDDEVICE1_HOME_ASSISTANT] (LedDevice.cpp:380) Stopping refresh timer2024-12-19T14:09:37.343Z [LEDDEVICE1_HOME_ASSISTANT] Device 'home_assistant' is disabled due to an error: '[400 Bad Request] - Check Request Body'2024-12-19T14:09:37.343Z [COMPONENTCTRL1] LED device: disabled2024-12-19T14:09:42.276Z [LEDDEVICE1_HOME_ASSISTANT] The LED device is not ready... trying to reconnect (try 1/60).2024-12-19T14:09:42.276Z [LEDDEVICE1_HOME_ASSISTANT] (LedDevice.cpp:63) Switch on2024-12-19T14:09:42.276Z [LEDDEVICE] (ProviderRestApi.cpp:174) POST begin: [turn_on] [{"entity_id":["0x04cd15fffe8de6e9"]}]2024-12-19T14:09:42.289Z [LEDDEVICE] (ProviderRestApi.cpp:198) POST end (13 ms): [turn_on] [{"entity_id":["0x04cd15fffe8de6e9"]}]2024-12-19T14:09:42.289Z [LEDDEVICE] (ProviderRestApi.cpp:203) Reply OK [200]2024-12-19T14:09:42.290Z [LEDDEVICE1_HOME_ASSISTANT] (LedDevice.cpp:391) Stopping retry timer2024-12-19T14:09:42.290Z [LEDDEVICE1_HOME_ASSISTANT] (LedDevice.cpp:366) Starting timer with interval = 40ms2024-12-19T14:09:42.290Z [COMPONENTCTRL1] LED device: enabled2024-12-19T14:09:42.330Z [LEDDEVICE] (ProviderRestApi.cpp:174) POST begin: [turn_on] [{"brightness":18,"entity_id":"0x04cd15fffe8de6e9","rgb_color":[83,0,0]}]2024-12-19T14:09:42.342Z [LEDDEVICE] (ProviderRestApi.cpp:198) POST end (11 ms): [turn_on] [{"brightness":18,"entity_id":"0x04cd15fffe8de6e9","rgb_color":[83,0,0]}]2024-12-19T14:09:42.342Z [LEDDEVICE] Reply error. Reason: [400 Bad Request] - Check Request Body2024-12-19T14:09:42.342Z [LEDDEVICE1_HOME_ASSISTANT] (LedDevice.cpp:380) Stopping refresh timer2024-12-19T14:09:42.342Z [LEDDEVICE1_HOME_ASSISTANT] Device 'home_assistant' is disabled due to an error: '[400 Bad Request] - Check Request Body' |
@satgit62 There is no such entity on the first screen with name "0x04cd15fffe8de6e9". It is even in an unusual format, did the user manually edit the configuration later by the hand? typically it should be something with the light prefix, for example light.0x04cd15fffe8de6e9 |
@awawa-dev , |
Still it's unclear for me from where entity "0x04cd15fffe8de6e9" appeared in the logs. Did the lamp work before you started to edit its layout. |
Unfortunately, none of the lamps worked, and there was no color change. Without adjusting the layout, it didn't work either. I then tried different layouts without success. I use a test file on the TV with RGB colors. |
Start the wizard again, do not edit them manually, then in the HyperHDR remote tab set a solid color for them. Save the full logs! |
Before that reset the HA lamp layout completely. Maybe it's broken after manually edition and providing not existing entity. To do that set LED driver to 'Debug', save it, refresh page F5 and set the HA lamps again. |
The lamps can be operated perfectly only via home automation. Thank you for your help!! |
Morning. Night shift? :) At least at the beginning I get moderate timeings
|
And z2m still goes crazy, i can not disable @ remote in webinterface. Log is quiet but light do something and go on. |
I previously suspected that it was getting clogged on the controller side/not HyperHDR or MQTT broker. And the actual timeout before it gives up is more than 200ms, which is why the queue grows then. Besides, you can do an experiment by disconnecting one lamp from the power supply while the system is running: the second one will desynchronize, although the real communication with it is, say, 50ms, the absent one will block the controller. I usually have no undelivered messages. We'll see if ZBDongle-P changes anything. On my CC2531 I have also some prehistoric firmware (zStack12 20180507) but I'm not sure if it's related. The question: how to decrease the actual timeout in the Zigbee controller ❓ |
Oh, so then z2m is a bottleneck...at the moment |
As a last resort I will fork zigbee2mqtt and cut off all transmission control 😈 |
Auć 🤐 Discord access to zigbee2mqtt server required: https://discord.com/channels/556563650429583360/557318913466171447/1193592939830591588 |
:( so z2m has some performance issues... https://discord.com/channels/556563650429583360/557318913466171447/1193607032708808744 |
If you are using EZSP stack then at least you can try lower RETRY_QUEUE_SIZE from 16 to 1 or 0 |
It's an error queue size. I need to find where the ordinary queue is handled for Z_STACK and limit it. |
If we can limit queue to ~5 or so (max number of lamps) then probably we can remove synchronization from HyperHDR. |
Nah, i'm using the ember stack. Will take a look. Edit: I will test this first |
If it's CDC serial port then the speed should not matter. I set 2000000 and still works without any change. |
Mh, then i must build one by myself it think: |
I set the speed in ZigBee2mqtt configuration. Usually if it is standard UART it won't work if the program for example on Arduino is using different speed. From my experience with LED drivers virtual CDC always using highest speed. |
Oh my, I forgot how much I hate TypeScript, definitely worse even than Python but I'm slowly getting through their code 😵 |
So far I've manage only to pin-point the root of the evil for all adapters: |
I tried something like this, without luck.
Yes, break. Next year is enough time :) |
@schwatter It didn't give me peace and I don't want to start the New Year with it 😉 https://github.com/awawa-dev/zigbee-herdsman/blob/1c8d8864da7f89c8f18b5290150277ec61f5d873/src/controller/model/endpoint.ts#L826 in
finally restart zigbee2mqtt service:
|
Woho good find. 10000 MS LMAO. |
Morning, The log at hyperhdr is now quiet. Z2m work with some delay around 36s. and throw me sometimes errors, |
At the moment i'm testing with timeout: 400, delay is around 4 - 6 sek. Much better. And at the moment it is stable in z2m. Normally z2m bombs me with errors and infos. Now it is quiet. edit: |
Hi |
Yes, i reverted my changes and insert your changes just with 200 - 400 ms. I have still a timing problem. I would say, broker and ember.
|
That's normal and intended. Otherwise it would try to deliver the message for few hundred ms (or 10000ms) blocking this device in the queue. |
In any case, despite this error message in logs, the message should have been delivered, the device simply did not confirm receipt in time. Philips Hue lamps are able to work at least 50Hz (at least that is the recommendation in the API), which gives 20ms for communication, so at least according to their recommendations, we do not overload the network. |
Happy new year! Overall, good work! With mosquitto the delay is minimal. Now i have to sort out, how i bring all together (Smarthome, Ambilight). |
I test now mosquitto setup as a bridge. That looks promising. |
I'm still working on zigbee-herdsman module currently. After receiving CC2631p concurrency jumped to 16 reveling some unwanted side effects (despite 16 still zigbee executes 2(my lamps number) connections at once but concurrency blocks the queue cleaning). |
I think we should move with development to new topic: #1024 |
Work is finished. Unique features for this implementation:
Implements #918
Home Assistant configuration
I assume you've already configured your lights in Home Assistant. The photo below shows Philips Hue lights connected via a ZigBee adapter.
If the lights work properly in Home Assistant, you need to create one more thing necessary to support them in HyperHDR:
Long Lived Access Token
.You will find the required option in the Home Assistant user security settings as in the screenshot below.
You must copy it immediately when creating and save it.
HyperHDR configuration
Open HyperHDR and go to LED Hardware. Select "Home Assistant" from the tab and then click the button to launch the configuration wizard.
By clicking the
Select Home Assistant
button you can see the list of instances that HyperHDR has found and choose the one you are interested in. Then below you need to enter theLong Lived Access Token
that you created earlier in Home Assistant. When finished click theContinue
button.On the next page HyperHDR will display all the supported lights it found in the Home Assistant instance. Now you can assign them a default position to the screen and intuit each of them (it will be turned off and on) so you can see which lamp you are configuring. You can always fix this configuration later in the LED layout editor. When you are done, save your changes.
Congratulations! That's all. In the options you can also:
choose between the RGB or HSL model. Each of them behaves slightly differently and it also depends on the lamp model how/whether it supports it or not
set
transition time
which will provide smoother color transitions at the expense of delayby default
brightness
is dynamic and depends on the brightness of the selected color. However, you can change it and force it to be fixedif you want HyperHDR to restore to the original state it found at startup when turned off, check the option: restore default state