Supported hardware list

[sde1000]

Supported hardware list

[sde1000]

Not currently, but the serial protocol described at https://atxled.com/pdf/AL-DALI-HAT.pdf looks reasonably simple so driving it shouldn't be too difficult.

[dgomes]

You even have python example code: https://atxled.com/Pi/code.php

[SummerSeaSun]

Thank you, may I ask you also about this one:
https://helvar.com/it/product/510-usb-dali-interface/

[sde1000]

I don't have any information on the USB protocol used by that Helvar interface (they don't appear to publish it, and I've never had access to a sample for reverse-engineering). Not currently supported.

[SummerSeaSun]

I have a sample available from Linux it load show as:

 1357.635179] usb 1-6: new full-speed USB device number 12 using xhci_hcd
[ 1357.784706] usb 1-6: New USB device found, idVendor=16eb, idProduct=0510, bcdDevice= 9.00
[ 1357.784710] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1357.784713] usb 1-6: Product: 510 Digidim Interface
[ 1357.784715] usb 1-6: Manufacturer: Helvar
[ 1357.784717] usb 1-6: SerialNumber: 000000011960
[ 1357.786973] hid-generic 0003:16EB:0510.0005: hiddev2,hidraw4: USB HID v1.00 Device [Helvar 510 Digidim Interface] on usb-0000:00:14.0-6/input0

I can do some test if you can tell me what to do.
Thanks

[sde1000]

Ok, so it's showing up as a generic HID device.

To work out what the protocol is, I would install the DIGIDIM Toolbox software on Windows in a virtual machine, and give it access to the USB device. Use the Toolbox software to send DALI commands through the interface while watching the USB traffic on Linux using Wireshark.

[pkonecki]

Hello,
I am interested too in support for Helvar 510 USB.

I have installed the Digidim software on a windows machine connected to usb to the Helvar 510 and made a capture using Wireshark while sending dim and on off commands.
Here's the capture: dali.zip

Don't hesitate to tell me if you need any further testing or another capture.

[sde1000]

It would be helpful if you could run some queries so we can see examples of reading backward frames from the device — all the USBHID frames from the device in that capture appeared to be simple acknowledgements with no data.

Can you describe your test setup, too — what do you have connected to the DALI bus? Have you assigned addresses to the control gear and/or devices?

[pkonecki]

Hi, sorry for the long delay, I was out of the office.
Here's the setup:

And here's a capture done when starting the application, during which there's a scan of the dali network, which I guess does some queries.
init.zip

[pkonecki]

Hello again,

I have found an implementation of the usb driver for helvar510 in rust.
I have tested a bit and it seems to work: https://github.com/fluffware/dali_tools/blob/master/src/drivers/helvar/helvar510.rs
Maybe you can use it to extract the needed infos for python-dali?

[pkonecki]

I have found a command history in the Helvar Toolbox app describing all commands passed and reply received with hex codes. I have redone a capture and exported the command history to a csv file, you can find them both attached:
cap.zip

I have begun reading the code in hid.py to see if I could adapt an existing driver but I cannot make sense of the first 2 bytes of each commands in the capture.

[sde1000]

Here are some notes based on that capture:

02 82 04 00 - some kind of initialisation packet?
 - response 03 82 09

03 d2 a5 00 - send a500 twice, no reply expected
 - response 01 64 09
03 50 b1 ff - send b1ff once, no reply expected
 - response 01 64 09
03 50 b3 ff - send b3ff once, no reply expected
 - response 01 64 09
03 50 b5 ff - send b5ff once, no reply expected
 - response 01 64 09
03 50 b7 ff - send b7ff once, no reply expected
 - response 01 64 09
03 54 bb 00 - send bb00 once, check for reply
 - response 01 6b 09   - "No Reply"
...
01 8c a1 00 - ?????
 - response 01 8c 09

03 d2 a5 ff - send a5ff twice, no reply expected
 - response 01 64 09

03 54 a9 00 - send a900, reply expected
 - response 01 6c 09   - "Multiple Reply"

03 54 a9 00 - send a900, reply expected
 - response 02 6d ff   - "Yes (255)"

03 54 b1 0f - send b10f, no reply expected
 - response 01 64 ff

So it looks like the first two bytes of the packet sent to the device are some kind of command code:

• 0282 - unknown, some kind of initialisation code?
• 018c - unknown, this gets sent after "TERMINATE" but before "INITIALISE"
• 03d2 - "send twice, no reply expected"
• 0350 - "send once, no reply expected"
• 0354 - "send once, check for backward frame"

Then the second two bytes of the packet appear to be a 16-bit DALI frame.

In the response, the first two bytes appear to be some kind of type code:

• 0164 - reply not checked for
• 016b - "no reply"
• 016c - "multiple reply"
• 016d - "reply received", backward frame is in third byte
• 0282 - unknown
• 018c - unknown

Probably enough to start experimenting. No indication that the device supports 24-bit frames, so try writing a 16-bit only driver?