CommandTracking is completely broken about python-dali HOT 10 CLOSED

In what way is it broken?

from python-dali.

The _commands property doesn't seem to exist, unless you intantitate these classes. I didn't found any solution, rather than registering these command types by hand.

Was from_bytes were broken before?

from python-dali.

Are you using python 3? The way metaclasses are declared has changed between python 2 and python 3:

Python 2:

class foo(object):
    __metaclass__ = bar
    pass

Python 3:

class foo(metaclass=bar):
    pass

from python-dali.

Is there any chance to make it work with version (at the same time)?

from python-dali.

It's a bit of a pain; you either write it in quite a convoluted way, or make use of a compatibility library like six.

How important is python 3 compatibility to you at the moment? I think I mentioned before that I do intend to port this to python 3 at some point, but keeping python 2 compatibility is important to me for now; I make use of this library in some pubs that use quicktill which is python 2 for now. (Although, having said that, it might be time for me to look at converting quicktill to python 3 now most of its library dependencies have been ported.)

from python-dali.

I'll rollback my changes to see if it's broken under py 2.7 or not. I'll also get know that if py3 is really nesesarry, or not. (I'm fine w/ py2, but the environment, where it will be used... )

from python-dali.

What exactly does the _devicetype parameter in the commands, and how it sohuld really work?
Now, from_byte lead me to (call) stack overflow.

from python-dali.

IEC 62386 defines many different types of control gear. Some commands are common between all of them; these are defined in IEC 62386-102. Other commands are specific to particular types of control gear, for example fluorescent ballasts, emergency lighting controllers, LED lighting controllers, and so on and these commands are defined in IEC 62386-201, 202, 203, ... Part 201 defines commands for device type 0, part 202 defines commands for device type 1, and so on.

These device-specific commands (referred to in the standard as "application extended commands") all occupy the same "space" - they are encoded in ways that conflict with each other. To issue one of these commands, you first send the EnableDeviceType(n) command with the appropriate value of n, so only devices of that type will respond to the command.

When you are decoding commands from their packed representation back to Command object instances, you need to specify the type of device the command is for so you get the right one. If the previous command was EnableDeviceType(n) then the device type is n; if the previous command was anything else then the device type is 0.

from python-dali.

if you want py2/3 compatibility (which actually is a good idea) with metaclasses, take a look at http://stackoverflow.com/questions/18513821/python-metaclass-understanding-the-with-metaclass

from python-dali.

It seems ifex by now, I'll stay with using py 2.7

from python-dali.