Phillips Dynalite Integration for Lights (New Frontend Usage)

I have a house which consists of 100+ lights. Currently, I’m controlling them through the Control4 integration but would like to move away from that due to relative instability. The lights are all phillips dynalite.

I was dreading using the old yaml configuration and since the recent HA update, the integration is now controlled in the front end.

I set it up, and auto-discovered all the lights, there are 221 different devices detected by the integration, which sounds correct.

Now, states of the respective zones updates super quickly, so if i turn off the light from HA, they turn off. If i try turn off the zone, there’s no change in the actual states of the lights.

TL;DR, changes from HA C4 integration show on dynalite state (such as turning off the light), but changing the dynalite state does nothing to the state of the actual light (as if it doesn’t work)

Can anyone help me troubleshoot?

Happy to provide logs/whatever needed

I spent around 30 hours testing the Home Assistant integration for compatibility with my 2009-2010 Philips Dynalite system. This testing is part of a hotel system revamp project, where HA will replace the 15-year-old AMX automation. I run HAOS centrally on a virtual server and utilize a PDEG per room, creating separate hosts for each room.

Observations:

  • Single Channel Performance: Areas controlled by a single channel operate smoothly, supporting both ramping and preset functionalities without issues.
  • Multi-Channel Complexities: Challenges arise in multi-channel areas, especially when issuing command to those areas for all channels with joins. While dimming through Home Assistant (HA) executes flawlessly, issues manifest when using Dynalite controls for dimming and ramping. Specifically:
    • Initiating a change from 0 to 100% brightness with a one-second ramp results in a Dynet command that checks and replies with each channel’s status within the area. Unfortunately, during ramp-up, the brightness level is inaccurately registered at approximately 15-20%, causing the HA dimmer to display a nearly empty state, despite the lights being fully on. A similar discrepancy occurs when dimming, with the lights off but the dimmer indicating nearly full brightness. This reverse synchronization persists even when the ramp duration is reduced to 150 milliseconds, albeit with slight improvements.
    • At times, Dynalite button presses fail to elicit any response. Repeated pressing can overwhelm the system with commands, leading to significant operational delays and instability.
  • Zero Ramping for Accurate State Feedback: Setting the area preset ramping to zero, essentially turning it into a switch, ensures accurate state feedback to HA.

Adaptations and Solutions:

  1. Adjusting Button Ramping: By programming all preset to all channels buttons to zero ramping, I eliminated the smooth lighting transition triggered by button presses, which, in turn, ensured accurate state representation in HA, despite slight delays between channel responses.
  2. Area Division for Efficiency: Dividing larger areas into smaller segments significantly reduced the volume of simultaneous commands, enhancing system responsiveness and synchronization. I found that limiting areas to four or five channels minimized delays and improved overall system stability.
  3. Channel Ordering: The sequence in which channels are organized within an area plays a crucial role in system performance. Strategically positioning a few switch channels at the beginning of the sequence allows their commands to be processed first, thereby enabling dimmers to achieve their final state before their status is reported. Although shorter ramping times can yield better accuracy, I opted for zero ramping to ensure complete reliability.
  4. Channel Reordering Limitations: Modifying the sequence of channels after their creation does not influence their operational order within the system; it remembers the initial configuration and processes commands accordingly. For example, if dimmers initially assigned to Channels 1 and 2 are moved to Channels 3 and 4, with switches taking their place, the system still processes commands in the order of C3, C4, C1, and C2. To effectively reorganize channels, one must recreate the area from scratch, ensuring channels are added in the desired sequence from the outset. Tip: Place the all related channels to unassigned area C1 first, to make sure they go to the correct order

Suggestion for Developers: Implement a solution where Home Assistant dimmers populate based on the target level, followed by a brief polling command to confirm the actual level, ensuring synchronization and accurate state representation.

you can update the state of individual channel via automation to call service (request channel level) every time there is a change on state or change in attributes in device entity.
same thing on the other way around if you want to update your area preset state. create another automation that will monitor any change in state of individual channel to do action if and then to check the state of the rest of the channels. if all the channels involved is all off then turn area switch off, it all the channels is all on then turn the area switch on.
from here all will be sync and updated even if you press on dynalite keypad.