Philips Dynalite integration. Dimmer states not populating properly. A suggestion

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.

The whole thing is broken and inactive.

If you see on this link, it looks good. Not broken as you said

Have you got it to report state? I will try OP’s method again and see if i can get it to work but last i tried was no success

Sorry for my delayed reply. I didn’t see the message.

The integration worked perfectly, as long as the room interfaces sending messages to channel 0 (all channels) with joins, have dimming value 0. Make sure you configure the protocol of the server port on the PDEG (I use 50000) to Dynet1

However, I run into another issue that made me change my approach. I have a hotel with 17 rooms and 17 PDEGs so I tried to configure 17 hosts where all had different IPs but the same area numbering (Area 2 for lights, Area 3 for FCUs etc). The result was a mess because HA ignores the hosts (PDEGs) and integrates Areas as the last one configured, disabling those previously configured. My only option was to renumber Areas with room number (like Area 112 for lights=Area 2 in room 101 etc), but that would create complications.

I went the other way, using a Dynalite PDDEG that acts as a supervisor, where each PDEG is configured with offsets corresponding to room numbers (11000 for room 101 so lights of 101 is now Area 11002). Unfortunately, this approach uses Dynet2 protocol, so the HA integration is not compatible. I am now using BacNet (provided by the PDDEG) and the Bepacom BACnet/IP Interface, for temp, setpoint and FCU presets, and CGI commands to the PDEGs IPs for lights