State Report request (msg:30) doesn't recognize level from 2nd channel

[ericflores]

I have Simply Automated US22-40T Series Dimming Switch with duplex support. It can handle one second load on channel 2. When I request a StateReport using upb-cli it reports correctly the level of channel 1, but ignores the level of channel 2.

Example:
Using network 33 and device 9, I used the UPB wizard to generate a string to request the current state (30). The generated string is as follows:
07002109FF30A0

These are the responses that I receive from the serial port:

Channel 1	Channel 2	Response
OFF	OFF	090021FF0986000048
ON	OFF	090021FF09866400E4
OFF	ON	090021FF09860064E4
ON	ON	090021FF0986646480

UPB-CLI decodes correctly those where Channel 2 is off, and ignores reporting the status of Channel 2 when it is on. I can understand that this is a edge scenario, since most UPB devices do not support more than one channel, and it would have been impossible for the author to test them. Specially considering that the documentation doesn't offer any example for this scenario either.

Analyzing the strings above, it looks like level for Channel 1 is reported in positions 13-14 while level for Channel 2 is reported in positions 15-16 (where 64, hexadecimal for 100 is reported). Looks that the code needs another parameter for reporting level from channel 2 (level: 100, level2: 100) or use a list to reports all the levels associated to the device (level: [100, 100]).

This is a fine piece of code, and hopefully I can learn enough JavaScript as for being able to contribute fixes myself. Right now I try, but this is code is too advanced for me. In the meantime, I'm will continue posting issues to make sure that we have a central place to document them.

This device also fails to obey the device commands from upb-cli too (goto, activate, etc), responding only to link commands, but I´ll investigate and provide complete reproducible examples in a separate issue later.

[DaAwesomeP]

@ericflores I apologize for my lack of complete attention to your issues. Unfortunately, I no longer have any UPB devices, so I can't help you to decode/debug or submit new code beyond a programmatic and theoretical understanding.

First, I would strongly recommend interacting with my UPB code from the programmatic side in node-upb. This code has no dependencies and is a more raw implementation of the UPB spec without any possible serial or CLI issues. Read through the readme as well as the decode function. I'm strongly considering deprecating this upb-cli repo because I can't maintain it anymore without being able to test on real devices. The node-upb repo has no dependencies and should stand the test of time. All of the code in both repos is not my finest work either, as I made them partly to better learn JavaScript/NodeJS. However, you're more than welcome fork it or submit pull requests for any added features or bugfixes!

You're right, I did not factor in support for devices with multiple levels. I now see that third argument at least on the goto command on page 53 of the spec.

One workaround would be to assign a link to every individual device channel and control and query them that way. In my own network, I used only links and no device commands, as I was able to set my Simply Automated switches to broadcast every link change. I could not get the switches to broadcast devices changes, and I wanted to maintain a database of what was on a off for a remote control/Web UI database. You can see an example of how to do this in UPStart for a Simply Automated switch here.