Modular relays

[RichardEWillis]

Dec 30 2021

Hello, Seasons greetings.

This is a fork of your code that I pulled back in November and used to extend the capability of the plugin, to support more relay board types. Take a look and see if it is worth integrating into the mainline at some point. I used it to add support for the "ProXR" serial protocol, used on the higher end industrial relay modules (of which I had one from relaypros (www-dot-relaypros-dot-com)).

Code still needs some polishing, and could be optimized, via refactoring, to use a few common methods for "state change" operations, triggered by UI events. I started to do this a bit but I was going to end up re-writing everything and so left it as-is.

There is a "null" relay plugin that does not do much except log or print messages when it is used. This can be used as an alternate relay board if you have only the basic GPIO-based one available. Check out the relay plugin registration file: octoprint_octorelay/relay_register.json.

One issue I have seen on Raspberry Pi's is that they can (annoyingly) attach a TTY to a USB/Serial adapter which the ProXR serial protocol does not like that much. I added some info on disabling the TTY using some systemctl settings but am not sure if it 100% fixed the problem. Perhaps using another type of serial adapter (connected to the relay board) would also fix this issue.

There is also another serial protocol used by some of the cheap Chinese relay boards that one sees on Amazon et. al. This protocol could be added in future, I have not yet determined what it is yet though... Certainly it is easily extendable to other relay types so lots of future expandability potential here.

Anyway, have a look and let me know if you want to pull it... will leave that up to you. It's in a different branch so it will not mess up your main development branch.

Cheers,

• Richard (rwillis@shaw.ca)

[RobinTail]

I like the idea of making relay an abstraction. However, I'd not want to host and maintain the drivers within the plugin. Their amount, versions and complexity will grow.
Instead, I'd like to seek for an opportunity to provide the consumer with ability to connect their own driver (abstract class compliant) in runtime.
Not sure yet how it could be implemented, but I'd prefer to devote the drivers responsibility to the plugin consumer.