PWM about mqtt-io

[flyte]

I certainly can. I'll have a think about how to implement it and get it done when I've got a little time to spare.

[flyte]

Hey @Gr4ffy thanks!

It's currently not implemented I'm afraid. There's no technical reason why it couldn't be, just not enough time in the day 😊

[dr-apple]

Perfectly thank you, you can also times times whether you can speed up the input of an input? It takes about 1 second until the change is recognized :-( This is too slow at a pushbutton ....

[flyte]

Yep, it's on the list - see #5 :)

[Gr4ffy]

Hi,
Great job @flyte
Is PWM implemented already?

[Gr4ffy]

Got it, thanks for the feedback.

[bosu1787]

no pwm yet?

[matthijskooijman]

I am also in need of PWM, so I was looking at implementing this, but I'm not sure what the best approach is. I'm not sure if I'll be able to find the time to actually implement this, but in the interest of moving this forward, here are some considerations I had while looking at the code for this. Feedback is welcome.

• One big question is whether this should be handled by the GPIO modules, or some new type of module (like sensors, but then for output). GPIO seems the easiest approach, since that allows reusing a lot of setup and event handling code. However, that works for modules like beaglebone and (I guess) raspberry pi that (I think) talk to hardware directly to set up PWM, but might be less suited to more generic modules. e.g I think libgpiod and /dev/gpiochipx has no way to configure PWM output. There is a /sys/class/pwm/pwmchipx interface, but that does require devicetree configuration to let the PWM driver take control of pins rather than runtime configuration. Of course, it can be acceptable that PWM output is supported only by some modules, and there could mabye even be a pwmchip-sysfs gpio module that only supports PWM output (to be used together with the gpiod module for regular GPIO for example).
• If handled by GPIO modules, configuration can just be done like digital_outputs (see docs), but some supports_pwm or enable_pwm directive needs to be added. I guess PWM-enabled pins can still also be controlled as regular digital pins (e.g. by passing on_payload as value instead of a PWM value), so all regular values can still apply as normal.
• Normal digital GPIO is now handled by digital_output_loop() (that converts on_payload/off_payload to a bool) and set_digital_output() (that logs and passes the value to the right gpio module). The easiest approach would be to generalize these methods to just pass either booleans or numbers, and let the gpio module call the right output method based on the type of value.
• An alternative approach that is a bit more explicit is to add set_pwm_output() next to set_digital_output() and add a set_pwm_pin() to gpio modules, letting digital_output_loop() call the right method based on the type of value.
• One step more explicit would be to use a different topic for PWM values, e.g. something like <topic_prefix>/output/<name>/set_pwm (which saves the "look at the content to decide whether to do PWM or on/off", which is a bit fragile). This would probably be implemented by letting _handle_digital_output_msg match the set_pwm topic and if so, adding a different kind of message to the gpio queue (maybe adding a type flag or so) so digital_output_loop() (which processes the loop) can dispatch to the right method. This approach is probably the most explicit and most appropriate, without needing much extra boilerplate code.
• A bit off-topic, but looking at the code, I wonder a bit about the code split between _handle_digital_output_msg() and digital_output_loop(). The former looks at the topic and handles set_on_ms and set_off_ms directly by dispatching a task, and puts regular pin updates in a queue that is handled by digital_output_loop() (which also matches the payload against on_payload/off_payload config). For the set_on/off_ms handling, the comments say this is done in a task to prevent blocking digital_output_loop(), but the latter also handles the timed_set_ms configuration by also dispatching a task, essentially duplicating the set_on_ms code in a different place. I suspect these different timed features might have been introduced over time, but looking at them now, it seems this code could be refactored to be simpler.