outputs pulled low at startup about mqtt-io

[flyte]

I somehow missed the initial parameter to setup()! That should fix the pulse issue above. I'll get that implemented now.

[bwduncan]

It works. Thanks very much! 😄

[flyte]

Thanks for the bug report - I'll see if I can sort this out today.

As far as the MQTT part goes, you should be able to set 'retain' to true, which will save the values for those topics and deliver them again every time a subscribed client (re)connects to the server. https://home-assistant.io/components/switch.mqtt/

[flyte]

It seems that the GPIO will return to its previous state when setup_pin is called. For example, if the pin was set high, then the software exits (calling RPi.GPIO.cleanup()), it will be reset to an input port and go 'low'. Then, when you start the software again and it calls RPi.GPIO.setup() for that pin, it'll return to the high state it was at before we called RPi.GPIO.cleanup(). The inverse is also true, in that if it was low, it'll stay at the low state.

This is clearly not an ideal situation. When you have devices attached to the GPIO pins such as you have, we want to minimise (eradicate) any non-deliberate state changes. To this end, I think that I may revert #16 and remove the cleanup to avoid the unnecessary state changes, and instead just silence the warning from starting in an 'unclean' state.

Does that match up with what you're experiencing?

[bwduncan]

Hi, thanks for the quick response!

I think that's expected, the GPIO pins are controlled through a shared memory segment, so all cleanup really does is say that the pin is an input. cleanup leaves the state bit alone, so setup will configure a pin to be an output again and therefore it will restore its previous state.

However that doesn't help if you have just rebooted or power cycled, since the memory gets zeroed, so when the pin is configured it will get pulled low!

Incidentally, I would have expected the pin to "float" if it's configured as an input, so if there is a pull-up or pull-down resistor in the circuit the behaviour will be well-defined. Obviously if you're using a breakout board you're at the mercy of the designer to say what will actually happen.

I think the reason for using cleanup is primarily to avoid damage to the GPIO pins. A pin shorted to ground will do bad things if it's an output driven high, but will do nothing if it's an input. I think it's worth keeping cleanup.

Does that make sense?

[flyte]

It does make sense.

I don't think I can, or should, prescribe the use of cleanup and/or any default settings, so I've made them both an option for now. Cleanup is currently per-module (as opposed to per-pin, although that is possible for the RPi.GPIO module at least), and defaults are per-pin.

The default setting, when overriding what happens during setup() (returns to high, then default setting of low takes place), causes a pulse of about 20us:

I'll see if there's a way of reducing or removing this unwanted pulse.

[flyte]

I've got it down to about 7-8us but I can't see a way of reducing it further without the RPi.GPIO library making some changes. I've tested it with an 8k pullup resistor and it indeed does not go low after cleanup, so you're right in your assertion that it floats instead. Hopefully this can be mitigated in the application circuits.

The horizontal scale is set to 5us on this image

I'll make a release with the default setting and optional cleanup shortly. I'll let you know once it's done so you can test it out. You may end up with the situation where setting the pin to an output might pull it down for 7-8us before the code is able to pull the output high as a default, but this shouldn't be enough time to switch a relay.

[flyte]

@bwduncan please try version 0.1.2 and let me know here how it goes!