Support for CodeMercs LED-Warrior modules?

[SlySven]

I have obtained a LED-Warrior14(-01) Module which is a (nice and cheap) I2C-DALI interface and successfully connected and operated it from a Raspberry Pi 2B to send DAPC commands to dim all the lamps in my test setup. However I haven't found much in the way of software to work with it - particularly to assign individual short addresses (the luminaires I have are actually fitted with old Tridonic emergency LED ones with a pair of 10 position mini rotary switches labelled "TENS" and "ONES" - they carry the DALI rather than the DALI-2 marking - but it has been impossible to find out anything about how those might act - if they were to set a short address I would have thought they would have been 8 way ones!)

The only thing I found and have used is https://github.com/davideloba/daliMaster_rpi which seems to have been devised to work with the "DALI Master" HAT for Raspberry Pis but that does not seem to be available anymore (and with the Wayback machine being off-line it has been hard to find anything about it) - however a single mention of a LW14 datasheet on the front page which led to the CodeMercs site suggested and was confirmed that my unit is compatible with the originally targeted unit. As it happens the Raspberry Pi version is derived from an Arduino one by the same person and both mention that the chip used in "DALI Master" units is the CodeMercs one. Unfortunately this software is too simple to do the initialisation process - and I am a C++ coder not a Python one - so trying to extend the code there to do that is proving to be a challenge!

tl;dr; Is it feasible for this project to support this I2C-DALI interface - I'm guessing with the addition of a further driver...

[sde1000]

I've read through the datasheet for the module. Thank you for bringing it to my attention — it does look nice and cheap! I'll try to get hold of a couple to experiment with.

A driver to support this interface should be fairly straightfoward. The daliMaster_rpi code you linked to looks like a good example for finding the device on the I2C bus and getting to the point where you can send and receive frames.

[sde1000]

Modules have arrived — I can't look at them straight away, I'm busy on other things, but I'll put together a test setup as soon as I can.

[SlySven]

Here's my test setup - all running off a 240-to-240Vac isolation transformer for (my) safety!

I've a number of these "Zumatubel" DALI1 dimmable emergency luminaires (Circ. 2017) - by connecting just one of them to the controller I was able to set its (short) address and then address it individually - but working out how those two 10-way switches to set the short address (if that is what they are for) function has not been possible so far. The manufactures datasheet archive fails to mention this (obsolete) ballast model at all! :rolling_eyes:

One advisory I would give you for the CodeMercs module - although the PWB is a double-sided through-hole plated one the pads for the power/I2C/address setting are rather small and skimpy - I broke the ground pad away from the surrounding copper very quickly and had to reconnect it with a bridge to another point in the same circuit (to a pad used for the +5V regulator for the -02 module that draws it's power from the {then no-longer isolated from the} DALI power supply lines {and thus not the "Mains" wiring either})! So take care with the wiring up - and maybe consider through hole "pins" if one is going to connect/disconnect from those connections more than once...

[sde1000]

I've soldered a header onto mine. Very fiddly — tiny pads!

Here is a first attempt at driving the module. If you run this on a Pi with the module at its default address of 0x23 (i.e. both address pins floating) it should attempt to assign a new short address to all connected control gear.

This expects python3-smbus to be installed (same as the daliMaster_rpi project), and python-dali to be on the current python path (so clone the python-dali repo, or install it from pypi).

It works for me but I haven't tested all the edge cases (eg. when multiple devices respond to a query).

# Sample code for CodeMercs LW14 with python-dali on Raspberry Pi I2C

from dali.command import Command
from dali.gear.general import EnableDeviceType, Off
from dali.address import GearBroadcast
from dali.sequences import sleep as seq_sleep
from dali.sequences import progress as seq_progress
from dali.exceptions import CommunicationError, UnsupportedFrameTypeError
from dali.sequences import Commissioning
import dali.frame
import time
import logging
import struct

struct_signature = struct.Struct(">HHH")


class I2C_RPI:
    def __init__(self, address):
        import smbus
        self.bus = smbus.SMBus(1)
        self.address = address

    def ping(self):
        self.bus.write_quick(self.address)

    def write_byte(self, register, data):
        self.bus.write_byte_data(self.address, register, data)

    def read_byte(self, register):
        return self.bus.read_byte_data(self.address, register)

    def write_bytes(self, register, data):
        self.bus.write_i2c_block_data(self.address, register, data)

    def read_bytes(self, register, length):
        return bytes(self.bus.read_i2c_block_data(
            self.address, register, length))


class LW14:
    def __init__(self, i2c, logger=None):
        self.bus = i2c
        self.log = logger or logging.getLogger(__name__)

        # Simple presence check — raises IOError if device absent
        self.bus.ping()

        # Read and check signature
        vendor, product, version = struct_signature.unpack(
            self.bus.read_bytes(0xf0, 6))

        self.log.debug("LW14 vendor: %d", vendor)
        self.log.debug("LW14 product: %d", product)
        self.log.debug("LW14 version: %x", version)

        if product != 14:
            raise Exception(f"Unsupported product ID {product}; expected 14")

        if version < 0x2000:
            raise Exception(f"Unsupported LW14 version {version:02x}; minimum "
                            f"version required is 2000")

    @staticmethod
    def _wrap(command):
        response = yield command
        return response

    def _send_frame(self, frame, wait_for_response=False):
        if len(frame) not in (16, 24):
            raise UnsupportedFrameTypeError

        # Wait for device to be ready
        status = 0x40
        while status & 0x40:
            status = self._read_status()
            if status & 0x80:
                # Bus fault — we can't continue
                raise CommunicationError(
                    "Bus fault while waiting to transmit")
            if status & 0x08:
                # "Valid reply" bit is still set — read command
                # register to clear
                self.log.debug("Reading command reg to clear old reply")
                self.bus.read_byte(0x01)
            if status & 0x40:
                # Still busy — wait a bit before polling again
                time.sleep(0.002)

        log.debug("Status before sending frame is %x", status)

        # Write frame to command register; the LW14 will transmit as
        # soon as the bus is free, according to the priority in the
        # config register
        self.bus.write_bytes(0x01, frame.as_byte_sequence)
        
        if wait_for_response:
            log.debug("Waiting for response")
            # Poll the status register. We are waiting for bit 0x04
            # ("Reply timeframe") and bit 0x40 ("Busy") to become unset.
            status = 0x44
            while status & 0x44:
                status = self._read_status()
                if status & 0x80:
                    # Bus fault — we can't continue
                    raise CommunicationError(
                        "Bus fault while waiting for response")
                if status & 0x44:
                    # Still waiting
                    time.sleep(0.0002)

            log.debug("Finished waiting, status is %x", status)

            # If "frame error" is set, multiple devices transmitted
            # replies.
            if status & 0x10:
                return dali.frame.BackwardFrameError(0)

            # If "valid reply" is set, check that it was a single
            # byte.  If so, it's a response. Otherwise it's an error.
            if status & 0x08:
                while status & 0x03 == 0:
                    # Poll until the reply is fully received and its length
                    # is available
                    time.sleep(0.001)
                    status = self._read_status()
                if (status & 0x03) == 1:
                    return dali.frame.BackwardFrame(self.bus.read_byte(0x01))
                raise CommunicationError(
                    "Forward frame received while waiting for backward frame")
            
    def _read_status(self):
        return self.bus.read_byte(0x00)

    def _set_priority(self, priority):
        self.log.debug("Setting priority %d", priority)
        self.bus.write_byte(0x02, priority)

    def send(self, command, priority=2, progress=None):
        # If "command" is not a sequence, wrap it in a trivial sequence
        seq = self._wrap(command) if isinstance(command, Command) else command

        self._set_priority(priority)

        response = None
        while True:
            try:
                cmd = seq.send(response)
            except StopIteration as r:
                return r.value

            if isinstance(cmd, seq_sleep):
                log.debug("Waiting for %f seconds", cmd.delay)
                time.sleep(cmd.delay)
            elif isinstance(cmd, seq_progress):
                if progress:
                    progress(cmd)
            else:
                self.log.debug("Sending %s", cmd)
                if cmd.devicetype != 0:
                    self._send_frame(EnableDeviceType(cmd.devicetype).frame)
                    self._set_priority(1)
                if cmd.sendtwice:
                    self._send_frame(cmd.frame)
                    self._set_priority(1)
                response_frame = self._send_frame(
                    cmd.frame, cmd.response is not None)
                self._set_priority(1)
                response = None
                if cmd.response:
                    response = cmd.response(response_frame)
                    self.log.debug("Response is %s", response)


if __name__ == "__main__":
    logging.basicConfig(level=logging.INFO)
    log = logging.getLogger()
    d = LW14(I2C_RPI(0x23))
    # Turn everything off while we work...
    d.send(Off(GearBroadcast()))
    # Assign addresses to all attached control gear
    d.send(Commissioning(readdress=True), priority=3, progress=log.info)

[sde1000]

On further reflection, I'm pretty sure this isn't doing the right thing when there's a frame error on backwards frames (i.e. when multiple devices respond to a command). The "Frame Error" bit is reset on every read of the status register, so will almost certainly be clear by the time we check it.

More experimentation is needed — should it be read in the loop where we are waiting for any of bits 0 and 1 to be set in the status register? Or before then?

I need to add more devices to my test setup!

[SlySven]

Looking at https://electronics.stackexchange.com/a/529867/124900 suggests that the "Compare" stage is where you are going to get the collisions if the search address is greater than the random address chosen by more than one unit (otherwise you'd get a valid "yes" if only one unit does or no response if none does). As such you only need two devices to start with I guess...

Am trying to get the above working on my system - not sure quite what I need to frob at the moment running into awkwardness because I am ssh -Y-ing into the Raspberry Pi but because the operation has to be done with superuser permissions things are falling over when trying to communicate back via X subsystems given that root cannot access my normal user X-display - perhaps. 🤷‍♂️

On a more positive note there are good noises coming from the CodeMercs person running their forum if not more: https://forum.codemercs.com/viewtopic.php?p=13218#p13218

[sde1000]

I didn't need to run the script as root on my Pi. What happens when you try i2cdetect -y 1 as non-root?

[SlySven]

The command isn't available - it is /usr/sbin/i2cdetect - so that is not surprising... Don't forget that access to actual I/O hardware is normally a protected operation in a POSIX environment. 🤷‍♂️

TBH I am probably somewhat handicapped here as I am not familiar with Python at all (I know it is indentation/whitespace sensitive - which as a C/C++ coder is really strange to me! 🥴)

[sde1000]

On my Pi, with the default operating system installation, my user is a member of the "i2c" group and so has access to /dev/i2c-1. I didn't do anything special to enable this, it's just how it was configured out of the box.

steve@raspberrypi:~ $ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
steve@raspberrypi:~ $ ls -l /dev/i2c-1
crw-rw---- 1 root i2c 89, 1 Nov 10 20:33 /dev/i2c-1
steve@raspberrypi:~ $ id
uid=1000(steve) gid=1000(steve) groups=1000(steve),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),102(input),105(render),106(netdev),115(lpadmin),993(gpio),994(i2c),995(spi)
steve@raspberrypi:~ $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- 23 -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         

[SlySven]

Ah, I haven't given myself access to the i2c group:

ssh stephen@spock:~$ cat /etc/os-release 
PRETTY_NAME="Devuan GNU/Linux 5 (daedalus)"
NAME="Devuan GNU/Linux"
VERSION_ID="5"
VERSION="5 (daedalus)"
VERSION_CODENAME="daedalus"
ID=devuan
ID_LIKE=debian
HOME_URL="https://www.devuan.org/"
SUPPORT_URL="https://devuan.org/os/community"
BUG_REPORT_URL="https://bugs.devuan.org/"
ssh stephen@spock:~$ id
uid=1003(stephen) gid=1003(stephen) groups=1003(stephen),27(sudo),50(staff),100(users)

What PATH do you have?

[sde1000]

steve@raspberrypi:~ $ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games

[sde1000]

Apart from that, I'm curious about the issue you have running scripts as root. The script doesn't interact with X at all, it just runs in a terminal session — so how is accessing the Pi using ssh -Y causing problems?

What happens if you just run sudo bash?

[SlySven]

Whilst I am using elevated permissions on the remote (RPi) device I cannot run any GUI applications as they cannot connect to the XServer running on my local (GNU/Linux) PC.

ssh stephen@spock:~/src/python-dali$ sudo bash
root@spock:/home/stephen/src/python-dali# mousepad
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.

(mousepad:28405): Gtk-WARNING **: 18:53:54.574: cannot open display: localhost:10.0
root@spock:/home/stephen/src/python-dali# 

OTOH I might be able to sort out the access to the remote hardware parts by adding membership to some additional groups.

FTR my current path is:

ssh stephen@spock:~/src/python-dali$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/opt/vc/bin

so some tweaking to include some other "privileged" ones looks to be needed...

[sde1000]

Running X applications as root doesn't work because they are looking in the wrong place for the .Xauthority file that contains the cookie that allows access to the display. (They will be looking in /root/.Xauthority)

You can either add the cookie to root's .Xauthority file by using the xauth command to export it from your own .Xauthority file and import it into root's, or just get X clients run as root to look in your home directory instead:

sudo touch /root/.Xauthority  # Make sure file exists, otherwise xauth add will fail
sudo xauth add $(xauth list $DISPLAY)

or

sudo bash
export XAUTHORITY=/home/stephen/.Xauthority

[SlySven]

sudo bash
export XAUTHORITY=/home/stephen/.Xauthority

Do I want to do that on my local (PC) or remote (RPi) machine?