Berry examples repository

[darrylb123]

I've just spent a while writing some berry code. I had never used Berry before and, it seems, neither has most. There is very little Berry code to be found.
The documentation in Tasmota and Berry is very complete, except there are very few examples.
The Tasmota Cookbook seems aimed at showing off what Berry can do, very admirable but not helpful to a beginner.
Can I suggest that an area be made available that example code may be submitted to help newbies like myself.

I'd be happy to submit a few.

[sfromis]

https://github.com/tasmota/Berry_playground was created recently, with the intention of @dkebler getting it ready around Yuletide.

[dkebler]

best laid plans.... intention now is to get to this next week. @darrylb123 if you would like to assist help is appreciated. There will be a way to submit a pr to share your code efforts.

[darrylb123]

@kebler How is progress with the repo

[darrylb123]

@dkebler How is progress with the Berry playground?

[darrylb123]

Happy to. I've not tried to do anything substantial but have done a watering system with flowmeters in berry. I have implemented: Timers Cron Read and write counters Read and write tasmota relays Mqtt publish Mqtt subscribe Json handling in and out So I could produce examples of those very easily.

…

On Sun, 1 Jan 2023, 6:44 am David Kebler, ***@***.***> wrote: best laid plans.... intention now is to get to this next week. @darrylb123 <https://github.com/darrylb123> if you would like to assist help is appreciated. There will be a way to submit a pr to share your code efforts. — Reply to this email directly, view it on GitHub <#17490 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSUVNXNL5BJ44KQBZZT7DWQCLLJANCNFSM6AAAAAATHS42GM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[LucidEye]

I take it back... the script does indeed work.
I did not have my test hardware configured correctly.
My test hardware is only using a 4-channel relay (no 5th relay) so I needed to edit the script to this:
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]
if anypower != pow[3]
tasmota.set_timer(0, /-> tasmota.set_power(3, anypower))
end
end
end
MasterPower()

Now whenever relays 1-3 are on/off, relay 4 is also on/off!
I also noticed that if try to manually or remotely activate relay 4 when relays 1-3 are not on, it automatically gets shut off instantly, which is actually great, it will prevent the 24 VAC transformer from accidentally getting turned on when it shouldn't be.
I guess I make it permanent across reboots by uploading the script to the file system as a .be file?

[sfromis]

Yes, as mentioned, you can create the file autoexec.be. You can either have the code there, or load it using something like
load('MasterPower.be')

[LucidEye]

Thank you again very much for explaining all of this in clear detail.
I have it working as desired on my test hardware right now.
I will watch it for a few days before I try running it on the actual irrigation system.
Currently I have my 3rd-party automation software (Mycodo) managing this switching logic over MQTT.
But it takes 8 discrete automation functions (2 for each relay) to accomplish what that simple berry script can do.

And once in a great while, the ESP32 will fail to receive an mqtt payload due to WiFi interference, and the relays don't turn on (or off) in unison. I much prefer the micro-controller to be handling this switching logic, as it should be.... much more reliable.
If it is OK with you, I'd like to post this code with all of the corrected code comments in the Berry code section... seems like there isn't a whole lot in there yet, and I know this will undoubtedly be useful for others.
Thank you again.

[LucidEye]

2 more questions...
Once I have the autoexec.be file uploaded to the file system, I can delete the .be file once I see the .bec file appear, correct?
Once the autoexec.bec file is created, does it get backed up when I do a Backup Configuration, or do I need to upload the autoexec.be file every time I need to re-flash a new ESP32 with these configuration settings?

[sfromis]

Sure, you can delete the .be file, but usually there is no good reason to do that. Do keep a backup somewhere.

And no, the Backup Configuration function does not back up any files you have in the file system. So, yes, you'll have to recreate the file for new devices, unless you do a custom build including a pre-populated file system.

And I put no restrictions of what you do with the sample code I posted here 😄

[btsimonh]

this would really help me....
simple things like how to trigger a berry function from a digital input/hadrware button evade me after 2-3 hours of playtime.

All I want to do is to trigger something from MQTT, set a 'relay', then count pulses from a 'button', and turn off the relay after a configured number. (auto fish feeder - pulses -> portions).

@darrylb123 - I found your repo here
https://github.com/darrylb123/tasmota/blob/main/flowmeter.be
and it has most of what I need apart from reading a button, which I think I can do from a rule (but there is a better way?). :). thankyou.

[barbudor]

If the GPIO is defined as a Button or a Switch then all Tasmota rules trigger can be applied, once you have eventually detached such button/switch from relay if there is one

Alternatively you can use as a 'gpio' (define nothing or INPUT in the template/module configuration) and poll that in a timer based function 'a la Arduino'

[btsimonh]

Thankyou @barbudor - I went the rule trigger route...

with the example from @darrylb123 repo, I have come up with the below (in about an hour :) ).

Things to highlight:

Repeatedly running code in the berry console is cumulative - especially and obviously adding tas rules :).
At least when developing, best to remove then add.... else you end up restarting a lot.

It's not obvious that the function added with add_cmd should end with a tas response to be sent (e.g. tasmota.resp_cmnd_done() ).
Else I got a cryptic error BRY: ERROR, bad json: OFF

br,
Simon

# A simple Berry example.
# Operates an automatic pet feeder (an old CAT feeder)
# the purpose here is to respond to a commmand 'feed n'
# if n > 0, then a motor is started, and a counter set to n
# every time switch1 transitions to ON, a counter is decremented.
# when the counter reaches zero, the motor is turned off.
# in my case, I've used a spare hbridge to provide the motor drive, so setup relay1, relay2 as the hbridge controls.
# I've set switch1 as the switch operated by the feeder deliveing one portion of food.
# note the setting of swicth options from berry.
# note the REMOVAL of rules and cmnd before adding.

import json
import string
#import mqtt
#import persist

# define relays for motor hbridge
var forward = 0
var backward = 1

# a variable to count how many portions we have fed this time
var portion_counter = 0

def feed(val)
  if val
    # turn motor forwards if val != 0
    tasmota.set_power(forward,true)
    tasmota.set_power(backward,false)
    portion_counter = val
    print("feed", val)
  else
    # turn off motor
    tasmota.set_power(forward,false)
    tasmota.set_power(backward,false)
  end
end

# this is called by using 'feed' in tas.
# note that it needs to respond... else you get a cryptic 'BRY: ERROR, bad json: OFF'
def feed_cmnd(cmd, idx, payload)
  print("cmnd from tas:",cmd, idx, payload)
  feed(int(payload))
  tasmota.resp_cmnd_done()
end

# example of direct mqtt - we will just use a cmnd
# hence not tested.
#def feed_message(topic, idx, payload_s, payload_b)
#	var feed_msg = json.load(payload_s)
#  
# 	if feed_msg['state'] == "start"
#    feed(4)
#  else
#  end
#end
#def subscribes()
#  mqtt.subscribe("cmnd/feed/control",water_message)
#end
#tasmota.remove_rule("MQTT#Connected=1")
#tasmota.add_rule("MQTT#Connected=1", subscribes)


# this will be called from a rule in tas
def buttonTriggered()
  portion_counter = portion_counter - 1
  print("Switch activated")

  if portion_counter <= 0
    feed(0)
  end
end

# set switch 1 to report state, not toggle
tasmota.cmd("SwitchMode1 1");
# disconnect switches from relays
tasmota.cmd("SetOption114 1");

# note:
# if using the tas berry console, best to remove the rules first.
# because the old ones remain, and berry gets called multiple times.
# call our function every time the switch report on
tasmota.remove_rule("Switch1#State=1")
tasmota.add_rule("Switch1#State=1", buttonTriggered)

# our feed command - use like "feed 4" to feed a 4 portion meal.
tasmota.remove_cmd('feed')
tasmota.add_cmd('feed', / cmd, idx, payload -> feed_cmnd(cmd, idx, payload))

[darrylb123]

I had the need to do something similar on another application. It was interesting as I found that a closure was the way to achieve the result. Until that point, I couldn't understand what a closure was used for. Given that I had to maintain state within a time delay loop. https://github.com/darrylb123/wavetank/blob/main/softstart.be

…

On Tue, May 16, 2023 at 5:03 PM btsimonh ***@***.***> wrote: Thankyou @barbudor <https://github.com/barbudor> - I went the rule trigger route... with the example from @darrylb123 <https://github.com/darrylb123> repo, I have come up with the below (in about an hour :) ). Things to highlight: Repeatedly running code in the berry console is cumulative - especially and obviously adding tas rules :). At least when developing, best to remove then add.... else you end up restarting a lot. It's not obvious that the function added with add_cmd should end with a tas response to be sent (e.g. tasmota.resp_cmnd_done() ). Else I got a cryptic error BRY: ERROR, bad json: OFF br, Simon # A simple Berry example. # Operates an automatic pet feeder (an old CAT feeder) # the purpose here is to respond to a commmand 'feed n' # if n > 0, then a motor is started, and a counter set to n # every time switch1 transitions to ON, a counter is decremented. # when the counter reaches zero, the motor is turned off. # in my case, I've used a spare hbridge to provide the motor drive, so setup relay1, relay2 as the hbridge controls. # I've set switch1 as the switch operated by the feeder deliveing one portion of food. # note the setting of swicth options from berry. # note the REMOVAL of rules and cmnd before adding. import json import string #import mqtt #import persist # define relays for motor hbridge var forward = 0 var backward = 1 # a variable to count how many portions we have fed this time var portion_counter = 0 def feed(val) if val # turn motor forwards if val != 0 tasmota.set_power(forward,true) tasmota.set_power(backward,false) portion_counter = val print("feed", val) else # turn off motor tasmota.set_power(forward,false) tasmota.set_power(backward,false) end end # this is called by using 'feed' in tas. # note that it needs to respond... else you get a cryptic 'BRY: ERROR, bad json: OFF' def feed_cmnd(cmd, idx, payload) print("cmnd from tas:",cmd, idx, payload) feed(int(payload)) tasmota.resp_cmnd_done() end # example of direct mqtt - we will just use a cmnd # hence not tested. #def feed_message(topic, idx, payload_s, payload_b) # var feed_msg = json.load(payload_s) # # if feed_msg['state'] == "start" # feed(4) # else # end #end #def subscribes() # mqtt.subscribe("cmnd/feed/control",water_message) #end #tasmota.remove_rule("MQTT#Connected=1") #tasmota.add_rule("MQTT#Connected=1", subscribes) # this will be called from a rule in tas def buttonTriggered() portion_counter = portion_counter - 1 print("Switch activated") if portion_counter <= 0 feed(0) end end # set switch 1 to report state, not toggle tasmota.cmd("SwitchMode1 1"); # disconnect switches from relays tasmota.cmd("SetOption114 1"); # note: # if using the tas berry console, best to remove the rules first. # because the old ones remain, and berry gets called multiple times. # call our function every time the switch report on tasmota.remove_rule("Switch1#State=1") tasmota.add_rule("Switch1#State=1", buttonTriggered) # our feed command - use like "feed 4" to feed a 4 portion meal. tasmota.remove_cmd('feed') tasmota.add_cmd('feed', / cmd, idx, payload -> feed_cmnd(cmd, idx, payload)) — Reply to this email directly, view it on GitHub <#17490 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSUVM42TXMZAVSTBGTOJDXGMREPANCNFSM6AAAAAATHS42GM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[btsimonh]

I found another interesting construct using global.xxx where xxx is a variable you declare in the script.
When developing a 'driver' I found it a pain to have to keep restarting tas for it to remove the last iteration I had pasted in the berry console.
I could not get exception handling to work, but see tasmota/Berry_playground#2 for my workaround...

[btsimonh]

maybe place your closure code in an issue there - again it's innovative real-world use of berry, not at all obvious from any docs I've read!

[darrylb123]

Is that what we're supposed to do? Submit it as an issue. I've been expecting to add files to the repository once it was ready for use?

…

On Tue, May 16, 2023 at 8:08 PM btsimonh ***@***.***> wrote: maybe place your closure code in an issue there - again it's innovative real-world use of berry, not at all obvious from any docs I've read! — Reply to this email directly, view it on GitHub <#17490 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSUVKT6DXV2FQ62VNK7WTXGNGYVANCNFSM6AAAAAATHS42GM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[btsimonh]

no - I'm just playing fast and loose :). I have a million projects on the go at a time, and will have forgotten all my new berry knowledge by next week - so just needed somewhere where I could stash it where it may be useful to others.
I've suggested they enable the wiki on the repo - that's a good way to get the public to contribute to what is effectively docs.... but can be a little uncontrolled.

[sfromis]

As things are now, it looks like @dkebler dropped the ball (?) when it comes to getting https://github.com/tasmota/Berry_playground active.

[darrylb123]

Yes, I've tried to prod him a couple of times, with no response. I have a little time, I'd be happy to assist getting it up and running. I assumed that it would be treated like a code repository, with some kind of structure and examples by others would be in the form of pull requests. A wiki might be difficult to keep some structure.

…

On Tue, 16 May 2023, 8:21 pm sfromis, ***@***.***> wrote: As things are now, it looks like @dkebler <https://github.com/dkebler> dropped the ball (?) when it comes to getting https://github.com/tasmota/Berry_playground active. — Reply to this email directly, view it on GitHub <#17490 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSUVK4HRXRN3FARFS6JBDXGNIK5ANCNFSM6AAAAAATHS42GM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dkebler]

Yes I've dropped the ball but it's still dribbling along the floor. Actually in the last month I have coded up (in node) a dev environment so one can work on berry code and have it automatically fetched by a tasmota device on changes and then have the device reboot. At least for me it's really speed up my dev cycle. I'd like to share it along with some apps (e.g. weather station, thermostat/hvac) and utility modules I've coded but like many not alot of extra time to document it and put it at playground (or linked).

what I think would be helpful at least it to activate the "discussion" of the playground repo so at least those interested can easier communicate and have a record of such. I don't have permission to do that. @sfromis or others would have to do it. Also anyone else who want publish rights to the repo should just ask @sfromis as my heart is bigger than my time when it comes to making the playground a thing.

BTW a good berry tool I found was this. https://github.com/fmtr/tappack. So there is reason for the playground if only there was time for it.

[sfromis]

I'm not the one to ask about permissions; I think that Jason2866 has the powers.

[darrylb123]

Opening the discussion sounds great. There should be some agreement on the structure and content. It would be a shame for it just to end up as a code dump. I'd like to see small concise files demonstrating a concept or feature. The structure might be based on the reference manual, with an example for each concept in each file, so a chapter might end a with several files in the playground.

…

On Wed, 17 May 2023, 4:50 pm David Kebler, ***@***.***> wrote: Yes I've dropped the ball but it's still dribbling along the floor. Actually in the last month I have coded up (in node) a dev environment so one can work on berry code and have it automatically fetched by a tasmota device on changes and then have the device reboot. At least for me it's really speed up my dev cycle. I'd like to share it along with some apps (e.g. weather station, thermostat/hvac) and utility modules I've coded but like many not alot of extra time to document it and put it at playground (or linked). what I think would be helpful at least it to activate the "discussion" of the playground repo so at least those interested can easier communicate and have a record of such. I don't have permission to do that. @sfromis <https://github.com/sfromis> or others would have to do it. Also anyone else who want publish rights to the repo should just ask @sfromis <https://github.com/sfromis> as my heart is bigger than my time when it comes to making the playground a thing. BTW a good berry tool I found was this. https://github.com/fmtr/tappack. So there is reason for the playground if only there was time for it. — Reply to this email directly, view it on GitHub <#17490 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSUVLNT6NL4YICCU5QXNDXGRYK5ANCNFSM6AAAAAATHS42GM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dkebler]

I agree with what you say. Maybe the playground repo can also hold a "utility" modules folder. But first let's see if we can get @sfromis attention to add the discussion to playground (we can try a discord if need be). At the very least why don't you close this issue and we can use the playground issues for now. Here is link to a playground issue to continue.

tasmota/Berry_playground#4 (comment)

[dkebler]

Now there somewhat of a structure and instructions for making contributions to the playground along with a discussion system so maybe @darrylb123 we can continue there.

https://github.com/tasmota/Berry_playground

tasmota/Berry_playground#3

[rug1024]

First of all: I am not a programmer, but trying to learn and understand. So you may laugh at me or ignore this posting, but I have not been able to find help elsewhere. Read Berry Cookbook, studied other scripts , etc. , even asked AI (CoPilot), but those results are not working. By the way: CoPilot can create complex working Tasmota-Rules, it just fails with Berry.

My Hardware: ESP32, MAX7219 LED Matrix Display, Brightness sensor BH1750.
What I am trying to do (in Berry-Script): set the brightness (DisplayDimmer) of the LED-Display according to the surrounding brightness (4 steps), executed every 30 seconds.
Working Berry-Commands I have found out so far: tasmota.read_sensors("BH1750") (output needs formatting) and tasmota.cmd("displaydimmer 10")

I currently have this task working with Tasmota-Rules, but I also want it to work in Berry, mainly for learning purposes so I don't have to bother you with stupid questions in the future. Really looking forward to your hints. Thanks in advance! Regards...

[Jason2866]

@rug1024 Questions are welcome. Better to open a new discussion with a specific headline.
Way better chance to get an answer than posting the question in a not really related discussions topic.

[dkebler]

@rug1024 even better would be to open a discussion topic at the berry playground. Then you can get Berry specific help.

https://github.com/tasmota/Berry_playground/discussions/categories/get-help-q-a

also for "live" help you might try discord. THere is a berry channel in the Tasmota server. But you should really have a specific question. For general help the link above is better.

[sfromis]

To see a lot of sample Berry code, you can use this long list of Github repositories I've collected; the common thing is that they include Berry code, in almost all cases related to Tasmota.
http://sfromis.strangled.net/tasmota/berry/github-repositories