As a some-time firmware developer, to me the transition to CANbus is annoying but not so much fatal.
All CANbus really does is establish a "network" of the devices on the bike rather than use a 1:1 serial bus like UART. Less wiring required for more devices on the same broadcast domain, and allows things like the controller communicating "directly" with the battery and sensors rather than having to ask the motor to do so. This also ends up simplifying the firmware on the motor since it doesn't have to serve as a proxy for those other devices. Both CANbus and UART models accept commands and parameters over that connection, the distinction is that the UART models accepted a lot more parameters controlling firmware functions.
Put another way, CANbus didn't really lock us out, but the firmware Bafang wrote for the CANbus motor controller greatly narrowed the range of commands it will accept. It very easily could have gone the other direction and opened up even more customization (or remained the same), but they chose this path, limiting the control surface to wheel diameter and max speed. Stuff like reading torque sensors should now be a function of the CANbus network, and doesn't necessarily involve the motor.
Honestly, if they did it "right" there are no more control surfaces to discover until either Bafang adds them back or someone else writes and publishes their own firmware.
Regarding "change assist levels", my ideal firmware would allow me to specify an assist curve, or select a starting amperage and a linear, logarithmic, or exponential curve to apply according to the assist level thereafter. Even better if it also allowed specifying a maximum for a given assist level, so I could specify stuff like "PAS1 starts at 25W, maxes out at 250W" and "PAS10 starts at 250W, maxes out at 1500W", with a linear/logarithmic/exponential curve between.
All CANbus really does is establish a "network" of the devices on the bike rather than use a 1:1 serial bus like UART. Less wiring required for more devices on the same broadcast domain, and allows things like the controller communicating "directly" with the battery and sensors rather than having to ask the motor to do so. This also ends up simplifying the firmware on the motor since it doesn't have to serve as a proxy for those other devices. Both CANbus and UART models accept commands and parameters over that connection, the distinction is that the UART models accepted a lot more parameters controlling firmware functions.
Put another way, CANbus didn't really lock us out, but the firmware Bafang wrote for the CANbus motor controller greatly narrowed the range of commands it will accept. It very easily could have gone the other direction and opened up even more customization (or remained the same), but they chose this path, limiting the control surface to wheel diameter and max speed. Stuff like reading torque sensors should now be a function of the CANbus network, and doesn't necessarily involve the motor.
Honestly, if they did it "right" there are no more control surfaces to discover until either Bafang adds them back or someone else writes and publishes their own firmware.
Regarding "change assist levels", my ideal firmware would allow me to specify an assist curve, or select a starting amperage and a linear, logarithmic, or exponential curve to apply according to the assist level thereafter. Even better if it also allowed specifying a maximum for a given assist level, so I could specify stuff like "PAS1 starts at 25W, maxes out at 250W" and "PAS10 starts at 250W, maxes out at 1500W", with a linear/logarithmic/exponential curve between.
