zigpy-cli icon indicating copy to clipboard operation
zigpy-cli copied to clipboard

Expose flow_control paramater from zigpy

Open oliv3r opened this issue 1 year ago • 8 comments

Certain boards (such as the Sonoff Zigbee 3.0 USB Dongle Plus P) have a hardware switch that allows for turning on hardware flow control (given the correct firmware is flashed). This requires of course that zigpy-cli also allows for setting this flag to be able to communicate with the dongle.

Zigpy and zigpy-znp already support hardware flow control fully. No wit is time that zigpy-cli also offers this option.

oliv3r avatar Aug 10 '24 08:08 oliv3r

I have not yet tested this myself, as I first wanted to know if anything else is needed here.

I am in process of building the z-stack library with hardware flow control, but need something to test with, chicken and egg. I think this exposes everything correctly to zigpy, but I wasn't 100% sure. So this is also a 'verification step' to check if this patch is correct at all.

I will report later if this works or not, where the second bit will be hardware. Is my Z-Stack patch broken, did I forget to flip the switch, or is zigpy-cli not doing it for me.

oliv3r avatar Aug 10 '24 08:08 oliv3r

Is my Z-Stack patch broken, did I forget to flip the switch, or is zigpy-cli not doing it for me.

If you run zigpy-cli in verbose mode (zigpy -vvv), you will be able to see the radio connection parameters: "Opening a serial connection to %r (baudrate=%s, xonxoff=%s, rtscts=%s)"

puddly avatar Aug 10 '24 11:08 puddly

So first test shows the option to be working as expected.

voluptuous.error.MultipleInvalid: value must be one of [None, 'hardware', 'software'] for dictionary value @ data['device']['flow_control']
/ # zigpy -vvv radio --baudrate=115200  --flow-control None znp /dev/ttyUSB0 form

(yes, I am aware that None wasn't a valid string to begin with, but I wanted to trigger the error/see what happens :p)

/ # zigpy -vvv radio --baudrate=115200 --flow-control=hardware znp /dev/ttyUSB0 info 2024-08-16 07:35:19.955 fb5f17fa8e36 zigpy.serial DEBUG Opening a serial connection to '/dev/ttyUSB0' (baudrate=115200, xonxoff=False, rtscts=True)

/ # zigpy -vvv radio --baudrate=115200 --flow-control=software znp /dev/ttyUSB0 info 2024-08-16 07:36:22.957 fb5f17fa8e36 zigpy.serial DEBUG Opening a serial connection to '/dev/ttyUSB0' (baudrate=115200, xonxoff=True, rtscts=False)


It doesn't work yet for me (other then none, the default) as my firmware does not yet handle hardware flow control; and doesn't support software flow control at all anyway (so it just hangs, which is expected).

The commands get forwarded and interpreted properly however.

Not sure if it helps much waiting for the hardware flow control firmware, as any problems would be in znp or the firmware, not zigpy-cli. But feel free to wait for it.

oliv3r avatar Aug 16 '24 07:08 oliv3r

I think this is more explicit. There's various option, but the only accepted flag is passed. No room for ambiguity. Upstream does something similar as well anyway.

oliv3r avatar Aug 17 '24 09:08 oliv3r

rtscts and xonxoff are only really used by the serial port library. Zigpy only uses hardware and software (and none).

puddly avatar Aug 17 '24 18:08 puddly

Sure, but this is also what users potentially expect/look for? Eg z2mqtt talks only about rtscts, but zha uses hw/sw. I think this simply one of those QoL things ...

oliv3r avatar Aug 18 '24 08:08 oliv3r

They can always run --help, the options are all listed there. I'm not a fan of aliases like this, especially for development tools.

puddly avatar Aug 18 '24 17:08 puddly

They can always run --help, the options are all listed there. I'm not a fan of aliases like this, especially for development tools.

While I generally agree with you; I think here it does make sense to alias the values, to go with the common namings. Which is what zigpy itself even does; rename hardware to rtscs.

However, you are the boss; so I'll drop the aliases.

oliv3r avatar Aug 19 '24 21:08 oliv3r