search

sde1000 / python-dali

Library for controlling DALI lighting systems
Other
150 stars 73 forks source link

Supported hardware list #81

Open SummerSeaSun opened 4 years ago

SummerSeaSun commented 4 years ago

Hi, I've found this raspberry shield https://www.shop.atxled.com/products/dali-hat-for-raspberry-pi-b-and-b?variant=18469832884339 Is this supported? In alternative any suggestion on a cheap DALI2 to USB adapter is really appreciated. Thanks, BR

sde1000 commented 4 years ago

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 commented 4 years ago

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

SummerSeaSun commented 4 years ago

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

sde1000 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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:

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:

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