I would like to add the following code block to the playground: Parallel Switching Logic for Relays and Lights

[LucidEye]

First off I'd like to apologize for incorrectly trying to add this to the repository, I didn't understand the proper procedure.

User 'sfromis' was kind enough to write this code block to help me solve a technical issue and better understand how Berry works.

I believe this code could be very helpful to others as it was very helpful to me, so I think it should be posted here for everyone to benefit from.

This short script allows relays (or lights) connected to an ESP32 running Tasmota to be "linked together" in order to create automated parallel switching logic.
Parallel switching is useful for all kinds of electrical control scenarios where you would need to have multiple outputs activated simultaneously and need to assign the task to the micro-controller rather than have external 3rd party automation software perform this task via mqtt. Having the micro-controller perform this switching task locally is faster and more reliable than having it performed externally by 3rd party automation software.
Specifically, this script was written to control 5 relays, but can be edited for other configurations.
What this script does is to monitor the power-state of relays 1 through 4, and if any of them are on, then relay 5 is also automatically turned on.
Likewise, if any of the relays 1 through 4 are turned off, then relay 5 is also turned off.
Also, if relays 1-4 are off, then relay 5 can not be turned on, if you try to turn it on while relays 1-4 are off, then it will immediately turn off.
Likewise, if relays 1-4 are on, thus relay 5 is on, then relay 5 can not be turned off. If you try to turn relay 5 off while relays 1-4 are on, it will immediately turn back on.

Here is the script...

class MasterPower
  def init()
    tasmota.add_driver(self)
  end
  def set_power_handler(cmd, idx)
    var pow = tasmota.get_power()
    var anypower = pow[0] || pow[1] || pow[2] || pow[3]
    if anypower != pow[4]
      tasmota.set_timer(0, /-> tasmota.set_power(4, anypower))
    end
  end
end
MasterPower()

Here is a breakdown of what each line of code is doing:

First line defines a class, and last line instantiates the class to create an object.
The function of init() is initialization code for when the class is instantiated (creating an object).
The tasmota.add_driver allows the class instance to receive callbacks from Tasmota in many different situations.
set_power_handler() is just one of those, and it is only to be notified when a power status change happens.
tasmota.get_power() accesses a list of power states for all channels.
Index numbers in Berry starts with 0, and with 1 in Tasmota outside of Berry. Hence pow(2) matches Power3 etc.
tasmota.set_power() simply changes the state of one power channel.
Tricky thing is using the tasmota.set_timer(0, .... The reason is that the set_power_handler callback is not allowed to change any states, therefor the set_power call is deferred for 0 microseconds, meaning after exit from set_power_handler.

Berry code entered in the Berry REPL console is not saved anywhere. You can create a file autoexec.be with Berry code to be loaded after boot. When you use the console, the new code will in most cases supersede the old, but when using tasmota.add_driver the old iteration will persist. You can either reboot, build Tasmota with a development option providing a Berry restart button in the Berry REPL console, or you can change the init() method to:

  def init()
    tasmota.remove_driver(global.MasterPower_instance)
    global.MasterPower_instance = self
    tasmota.add_driver(global.MasterPower_instance)
  end

This allows the driver to remove the old version of itself, and then register the new instance.

The real-world use case:
I have built a custom irrigation control box to control 4 irrigation zone valves.
Relays 1-4 control the zone valves.
Relay 5 controls the 24 VAC transformer which energizes the zone valve solenoids.
Even when not under load, the 24 VAC transformer gets warm, and I want to keep that transformer powered off until it is actually needed in order to reduce heat buildup inside the control box and help protect the other components and extend their lifespan. Thus the need for the parallel switching logic.

If someone could please help me in getting this posted to the playground, I would appreciate it.
Thank you.

[dkebler]

This is great. A good addition. There is nobody available to massage your content, but can you follow the directions here?

https://github.com/tasmota/Berry_playground#contributing

If you have never done a fork/PR on a repo this is a good way to learn. There are many tutorial pages out there on how to do a PR on git(hub).

All you have to do is take the relevant parts of what you have written above and make it into a readme page in the "tutorials and code blocks" as part of a PR and bob's your uncle I can merge it.

https://github.com/tasmota/Berry_playground/tree/main/tutorial-code-blocks/virtualMembers Here is an example. When you fork the repo you could just duplicate this folder/readme page and then edit to suit.

This is also an opportunity to learn a little markdown. For code blocks you use triple back ticks before and after (single ticks for inline). Refer to any markdown syntax cheetsheat, and as I metioned if you use javascript as the code block type you will get some good highlighting for berry. https://www.markdownguide.org/cheat-sheet

Any problems with making a contribution just ask here in this thread. You contribution will be appreciated! I'm on vacation next two weeks but will be able to assist/merge as time permits.

[LucidEye]

I'm so NOT a programmer in any way other than on rare occasions needing to modify some python....
So I've never forked anything on github, so I'll try to muddle my way through the instructions as best as I can.
That's really cool that you can specify a language with the backticks to show color-formatted text... I had no idea I could do that on github posts.
That really makes code posts look much more professional. Thank you!
I found this other Markdown Cheat-sheet had better examples...
https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet

[dkebler]

In a nutshell to make a PR

1. Make a github account and login (which you have)
2. visit the repo in question.
3. click the "fork" button upper right.
4. that fork will now be a repo in your account.
5. install git and and vscode for editing on your personal machine. Add the git extensions for vscode.
6. click the "code" button on your fork (NOT the original repo) and then copy the url shown
7. do a git clone <the url> from a terminal on your personal machine (at a subfolder where you want to put the repo)
8. Edit the repo with vscode, and commit the changes (can be done within vscode)
9. When you are done "push" the code back to your fork.
10. From the fork ask to create a PR back to the original repo (this one).

This seems a bit daunting the first time but once you get this all setup up it's easy then to contribute to any repo. Even if you can't do much coding in a particular language I have found I can be helpful with doing documentation edits etc.

Once you have this set up then with vscode/git you will be ready to do future coding in berry or any other language and be able to share and save versions (commits). BTW since I am familiar with nodejs/javascript I find berry to very similar syntactically and otherwise, so it might be worthwhile to learn a bit of nodejs. Personally I'm a self taught coder. All the steps I outlined above I bumbled my way through at one point. Regardless of any coding language one needs to be familiar with an IDE (vscode) and using git. Vscode code can almost walk your dog it's very powerfull as a result of all the extensions out there.

Enjoy!

[LucidEye]

Thank you again... I very much appreciate the instructions :-)

I have been forcing myself to get more familiar with VSC over the past few months... I kind of had no choice after I started tinkering with ESP32s. So I'm vaguely familiar with PlatformIO, C++, and the Python IDEs in VSC. My problem is that I just don't need to do a lot of coding very often... maybe only once every 3-4 months, or more. So I just don't retain this stuff since I'm not doing it every day :-(
The last time I had any formal education in coding was in college.... 32 years ago... Python had just been invented 32 years ago :-P
Regardless, I just got VSC updated and working again.
Can you please clarify exactly which git extensions I need... there are over 200 extensions for git in VSC :-O
For now I have the "Git Extension Pack" installed.

[LucidEye]

9. When you are done "push" the code back to your fork.

OK... Been working at this all day and I am ready to be done with it. However VS Code is not cooperating as usual.
I keep getting this error when trying to Push the changes back up to my repository on GitHub.

I tried running Pull first, but it does not fix the problem.
Any suggestions?

[LucidEye]

Never mind.... finally got it sorted out.... had to do with the "block command line pushes" email setting in github.

Just posted the pull request.

Thank you.

[dkebler]

As relates to get extensions I think the later versions of vs code now include the basic git functionality. Beyond that you can add additional git functionality with extensions. Like commit graphs.