MatthewHink
commented
6 years ago Long and short of it. In synse 1.4 this was one call straight to the LED controller on the wedge. In synse 2.0 this is three calls from synse to the i2c plugin running on that wedge.
Two possibilities:
- Order of the calls is wrong. (state, color, blink_state)
- LED calls are going to the wrong wedge.
I know that the pcli command line tool will write to state, color, blink_state correctly either in one fell swoop or independently. Kill the containers and try it.
In one command line (one fell swoop), state is {on|off}, color is a hex int without the 0x prefix (such as FFAA11), blink_state is {steady|blink}.
The pcli tool writes in that order: state, color, blink_state and all three are required unless state is set to off. Otherwise it writes to each only independently (separate command lines).
Question: What order are these sent by Synse into this write function in the i2c-plugin? https://github.com/vapor-ware/synse-plugins-internal/blob/master/i2c/devices/pca9632/device.go#L84 The if (action) code blocks come in order of color, blink_state, state; but that should not matter if these are three separate RPC calls from synse to the i2c-plugin which I believe them to be.
If the three RPCs come in as state, color, blink_state in that order it should work.
The pcli tool setting state, color, blink_state all at once calls this; but from what I understand this is farmed out to three separate RPC calls from synse to the i2c-plugin. https://github.com/vapor-ware/synse-plugins-internal/blob/master/i2c/devices/pca9632/device.go#L238
Sample command lines:
# Get LED state on a wedge (VEC)
sudo -HE env PATH=$PATH ./pcli led
# Set LED state on a wedge (VEC) (on purple blink)
sudo -HE env PATH=$PATH ./pcli led on FF00FF blink
# Set LED state on a wedge (VEC) (on red blink)
sudo -HE env PATH=$PATH ./pcli led on FF0000 steady
# Set state only
sudo -HE env PATH=$PATH ./pcli led off
# Set state only (state arg required for on, optional for off)
sudo -HE env PATH=$PATH ./pcli led state on
# Set color only (green)
sudo -HE env PATH=$PATH ./pcli led color FF00
# Set blink only (blink)
sudo -HE env PATH=$PATH ./pcli led blink blink
# Set blink only (steady)
sudo -HE env PATH=$PATH ./pcli led blink off
# Set state only (state arg required for on, optional for off)
sudo -HE env PATH=$PATH ./pcli led state off
edaniszewski
when debugging an issue w/ writes to an LED controller, I saw that writing single values, e.g.
?color=ffffff, worked (would write, and then read back the written value -- this could take a little bit because of async writes) but issuing multiple writes, e.g.?color=ffffff&state=on&blink=steady, would sometimes not work. more specifically - one of the three that were set (in my tests typically state), were not read back with the new setting, but the other two often were.looking through the logs, each write request is being processed and seems to be completing successfully. the issue, it seems, is that the writes to the device are too rapid (one after the other) and in doing so, something goes wrong and at least one of the writes may not stick
the solutions that I can think of for this are:
both are sorta tricky implementation-wise. the second option also seems not great because while that write behavior may work for some devices, it may not work for all devices.
thoughts?