You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Already tried that. The thing is, the pin is instantiated with the defaults beforehand, and thus the device already has fired before the call to set_active_high. This happens after the initial boot of the Pi, but if you terminate the process and then restart it, it seems to work fine.
My suspicion is that the Pi OS does not know the default state of the pin and thus the first creation and subsequent operations affect the behavior until a restart. This could be a GPIO state bug that might be remedied in the future.
I made a couple of small changes to /boot/config.txt to set my desired pin to active_low. Limited testing indicates that may indeed work; however, seems like it would be unreliable per the documentation, and definitely overridden by any software. https://www.raspberrypi.org/documentation/configuration/config-txt/gpio.md
Been away from this project a while. Gotta get back into the swing of Rust after 6 month Java contract. If I remember correctly, directly emulating Python is not going to work because Rust does not allow optional parameters. Perhaps I will noodle with a few things and learn from that and have a suggestion, or a contribution.
The Python library allows both those parameters to be set on creation of a new OutputDevice.
It appears that these values currently are hard-coded to active_state true (high) and inactive_state false(low).
If using an active low relay, this is the exact opposite of what is desired.
rust_gpiozero/src/output_devices.rs
Line 108 in 8f3bdc7
The text was updated successfully, but these errors were encountered: