How should I approach controlling a DALI lighting system from Helvar from Home Assistant?

Hardware
1

Hi all,

I’m moving into a new house in a couple of months, and the house comes equipped with a DALI lighting system from Helvar called Digidim. If I remember correctly, it comes with at least two (or even three?) Digidim 910 routers to be able to support all light sources + a couple of PIRs. The routers will be connected to a local network switch that allows you to communicate with them over the local network.

I’d like to integrate this system in Home Assistant, i.e. read states (which lights are on?), listen to updates (light was dimmed), and send commands (turn off light). My challenge? I don’t have access to the system / the house yet, and there seems to very few folks here running DALI systems together with HA so there’s not much I can read up on in advance… :confused:

I did however find a brief mention of support for DALI gateways while scanning the KNX light integration in HA. Is anyone using that? I assume I’d need multiple KNX-DALI gateways since each gateway only supports 64 DALI devices… which seems like a bit of a hassle, but might be worth it if it “just works”.

In a better/perfect world, I could see my Helvar system communicating with HA over e.g. MQTT. This seems to be possible by purchasing a couple of DALI-MQTT gateways, but again - it feels a bit sad that I’d need extra equipment for that.

I also found @dgomes DALI <-> MQTT bridge, but again: that seems to require an additional USB device hooked up to the DALI bus. The bridge itself uses python-dali internally, which might be my last resort here.

Again: I do have the DALI routers from Helvar connected to the local network, so I assume (which I maybe shouldn’t, given that I can’t find any information on Helvar’s homepage) that I could communicate with the DALI lights/PIRs over TCP/IP… somehow :slight_smile:

At this point I’m somewhat confused, and would be eternally grateful for advice from folks who’s been up for similar tasks - please hit me with your best tips and tricks!

2

Before I forget it, I realise that I didn’t mention that HelvarNet exists - a TCP/IP protocol which allows third party devices (e.g. HA) to query and control a 905/910/920 router systems and perform some basic system configuration. Wrapping that to expose the lights and PIRs (for all routers) to MQTT would likely be the most clean setup. Anyone tried something like that?

3

The mention of Dali gateways in the Knx integration documentation refers to Knx-Dali-Gateways. To be able to use this you would need a functional Knx bus - Power supply, Ip-Gateway, cabling, etc. This is probably overkill (and just adds an abstraction layer) if you don’t want to use other Knx components.

Regarding the 64 device limit: I think this is some kind of Limitation of the Dali bus, but I could be totally wrong here as I have never used Dali.
However how many Dali devices/addresses does your house use? (1 per light group and 1 per PIR)

4

That is the way to go, I advise you to write a custom_component that speaks the HelvarNet protocol (following the specification you linked). By all means just forget that your light system is DALI, as the HelvarNet protocol is not DALI.

5

Yes, it does sound like overkill… and I’d love to avoid additional hardware. I think I’ll go down the HelvarNet route as discussed below.

6

Agreed - thanks for the push! Might expose it through mqtt to have a more generic implementation that could be used for other things than HA… time will tell.

2 Likes
7

Have you made any new progress on your project? I don’t know what kind of USB device to use

8

As for progress: no, haven’t moved yet so don’t have access to the system.
As for the USB part: Not sure I understand what you mean? The Helvar router(s) exist on the local network, so any computer/system that can talk TCP/UDP should suffice. My naïve approach would be to set up a Raspberry Pi on the local network that handles communication between the Helvar system and HA.

9

I’m very interested in the Helvarnet integration. Have you moved yet?

10

Actually, someone has made an integration with ELL-i, might be of use to create something for HA

11

I have moved, but haven’t had time for this yet. Still on my radar though!

12

I wrote a helvarnet binding for openhab:

It’s working well for me at home - but I’ve yet to polish it sufficiently for release - no docs.

You might find some of the parsing code helpful. Save some typing at least.

I may switch over to home assistant at some point in the future - at which point I’ll port this work.

Tom

13

@tom_tom: Cool - thanks for the pointer. Think I stumbled upon it when I searched GitHub for existing integrations :slight_smile:

I’ve got a super simple/scrappy Python app going that lets me interact with the Helvar system from the command line (listening for messages, as well as sending messages myself), but I stumbled on something that I wanted to explore further before diving deeper. It seems like if you’ve got multiple Helvar routers, you’ll need to initiate a TCP connection to each router to receive updates for all groups/devices in the system - connecting to a single router will only give you updates for any devices/groups that router handles.

I’ve reached out to Helvar to try to understand if there’s a better way to subscribe to “all” updates in the system. They seem to recommend UDP for HelvarNet in their own material, but I haven’t been able to get any updates when I use UDP - neither when doing unicast to one router, or when leveraging the multicast address.

Regardless: would be cool to at least explore the idea of sharing notes / codes / material. This might not be the best forum for it - open to any ideas you might have!

14

@usrlocal - I’ve not played with multi router setups - but was assuming that I’d need to initiate (and maintain) a TCP connection to each router. Not tested UDP. Might be something that needs to be enabled on the router itself?

Happy to share pointers - the code is up, and despite being Java it’s just about followable. I’d rather keep the conversation public so others can benefit. Git hub issues on the repo?

15

I’m thinking I might setup a new repo on GitHub where I start out by exploring some open questions / overall design of the system. Will post an update here once I get something up!

16

Here’s a start - feel free to join the discussion over at GitHub:

At this stage, I’m mostly trying to document the behaviour of HelvarNET and the Helvar routers, as well as any configuration / transformation needed (Helvar and HA are different beasts - things do not map 1:1).

17

@usrlocal
If would like to get live updates from the system just connect to port 50000(TCP) via packet sender orso and make sure you have enabled push message’s in the workgroup properties!. messages recieved will be in the same format as the command that you send.

you can find the push message’s option if you click the top level in de device panel and then have a look at the properties( should be near the bottom of the list)

@tom_tom
for multi router setup in a home setup you should be good to go to the first router( they will forward message’s internally)

If your going for larger setups it’s better to target the router you need

Kenny

18

Thanks for the pointers @Kenny-JTK.

Agree with your findings and approach @usrlocal.

I’ve made a decent start on an asyncio library for comms with helvar routers here: GitHub - tomplayford/aiohelvar: Asynchronous Python library to control Helvar Routers

It can:

  • Manage the async TCP comms well, keeps the connection alive and listens to broadcast messages
  • Decode the HelvarNet messages and translates things into Python objects that can easily be translated into hass objects
  • Discover and retrieve Devices, Groups & Scenes and and all their properties, state and values.
  • Keep track of device states as scenes and devices change based on notifications from the router.
  • Call most useful commands to control the above

Very much still a WIP. Tests don’t pass, and not everything is tested, documented or fully implemented :slight_smile: Needs a few more evenings.

I’ve also started to think through how things integrate with hass directly: GitHub - tomplayford/core at helvar

This is even more WIP. Although it’s functional:

  • It pulls groups and load devices from aiohelvar and represents them as Lights.
  • It allows those Lights to be turned off and on. Groups are toggled from scene 1 to 15.

Obviously a lot more to do here, but I’m still working my way through hass - this is my first integration.

I’m unsure how to map things scenes correctly. So far, I think:

Helvar devices => lights, or switches, or sensors
Helvar groups => Hass areas? or Hass lights?

In Helvar-land, scenes are pretty much the first class way of controlling things. Every light and switch is assigned to a group, then a set of scenes is defined for each group. Switches then choose a scene when pressed and the lights update based on the scene definition - I think hass should mostly calls scene changes on groups directly - as well as controlling individually lights, or sets of lights.

There doesn’t seem to be a sensible object to map Hevar scenes on to in the hass universe. I want to be able to create a UI element that would allow a users to select a scene for an Area (if groups are mapped to such). Hass scenes are rather different and not seemingly compatible. Would appreciate any thoughts anyone has.

I’ll keep plodding on when I have the time.

Tom

19

Great to see some activity in this thread <3

@Kenny-JTK: Thanks for the pointers! I think I’ve covered these in the (WIP) wiki that I referred to in my last post, but I’m still somewhat puzzled when it comes to the multi-router setup. I’ve got five routers in my local system at home, and from what I can tell some of the HelvarNET commands will not be automatically relayed between the routers. The HelvarNET documentation does say that messages will be forwarded, but nah… that’s not my experience. If you have insights, pointers or tips/tricks in this area, I’m all ears!

@tom_tom: Great timing! I have very little practical experience when it comes to writing HA integrations, but the overall design of the integration system seems sane. I would - just like the official docs/guidelines - advocate for designing the Python library to do the heavy lifting, and have the HA integration itself do any conversions needed. Seems like you’ve already zoomed in on this design yourself :+1:

I’ve also been thinking about the mapping between the two worlds. Looking at the Helvar system in isolation, groups and scenes are absolutely key. As for devices, one rarely interacts with these directly. I’ve got > 300 devices in my system (lights, relays, blinds controllers, rotary modules, multi-sensors etc), and the only time I’m directly interacting with them is when I configure them - think initial setup, replacing a device and so on.

The vast majority of the time during normal operations, I’m recalling a certain scene in a certain group. Each group usually contains some kind of input modules (rotary, on/off buttons etc.) as well as some lights or blinds. I’ve naively been thinking that you’d want to:

  1. Manually define what groups you’re interested in interacting with in HA (you might not care about all groups in the Helvar system)
  2. Manually define what each group represents (“light”, “blind”, “switch”)
  3. Likely: For each group, manually define what Helvar scenes represent on/off (for light), open/closed (blind) etc.

Example: I have a six downlights in one of ours room. These are grouped together in a Helvar group named “1090”, together with two rotary dimmers. The library should have no problem autodetecting that this group exists, but it will have a hard time understanding that the rotary dimmers are set to recall scene 1 (on) and 15 (off) - this is why I naively would say that you’d need to define this mapping yourself.

I think I would want the on/off functionality for this light (read: group) in HA to behave in the same way, e.g. calling light.turn_on or light.turn_off should do what the physical rotary dimmer does.

I’ll stop myself here - any input on the above?

Also: would you mind moving this discussion GitHub? Either repo would work fine. I’d also be happy to scrap my WIP repo and migrate some of the documentation to your Python library.

20

@usrlocal Thanks your your thoughts.

I think we agree that treating groups as lights is probably the way to go then. However I do want to be able to support the flow of allowing a user to set a specific scene on a group, and I can’t see how that’s done with a Light entity. Perhaps we create another entity for each group that will allow scene control - not sure which one to pick though.

I’d like to avoid manual config as much as possible, given that we can discover all groups, names and scenes pretty simply. Users can always remove groups they don’t want to track, I suppose.

Yes - please do move design thoughts to my repo - might as well centralise it all.

Tom