A Tasmota based Geiger Counter

[ullix]

I am using a Tasmota Plug via HTTP and I am quite pleased with the ease using it. This made me consider to use the Tasmota firmware for a Geiger Counter (to measure radioactivity).

The hardware isn't very complicated: a Geiger tube, a HV (High Voltage, ~400V) generator, pulse discriminating circuitra, a pulse counter.

The software - at its bare minimum - is simple: the firmware receives a call for data, and sends CPS (Counts Per Second), the counts aquired during the last 1 sec. That's it.

In more elaborate scenarios there would be a CPM (Counts Per Minute, sum of last 60 CPS) call, a setting of the HV (300...700V), CPS/CPM storage for the last day, week, month.

I had programmed this already (in C++); it is not very difficult. But putting this in Tasmota --- where would I even start ?

[sfromis]

With Tasmota, you can get by without any programming, as a starting point. If configure a counter gpio (assuming electrical compatibility), Tasmota can count pulses. If you set a telemetry period of one minute, along with SetOption79 for reset, the MQTT reporting will become CPM.

You can collect data backend, or with ESP32, you have the Berry language where you could code some aggregation in local files.

Whatever you do for the HV setting is up to how the hardware for that works.

Also see these threads on the topic: #18449 #18901

[ullix]

It looks like there is more discussion than what I expected from not finding "Geiger" in the Deice repository :-)

Your suggestions sounds very manageable. I do have the hardware which creates the logic pulses, and the ESP32 Dev Kits. It sounds like I can use some generic Tasmota? Where do I find this and hopefully guidance on how to install it on an ESP32? And also guidance on compiling, preferably on vscode?

[sfromis]

You don't need any compiling, as the standard precompiled binary should work for you, unless you just want to dive into driver coding.
Still, the docs has much info, including https://tasmota.github.io/docs/Compile-your-build/

[joba-1]

The readme of this repo has all those infos and links to more details.

[ullix]

Thank you, found 'tasmota32.factory.bin', flashed my 'ESP32-WROOM-32E', set the IP, configured 'ESP32-DevKit (1)' GPIO18 as 'Counter 1'. Counting works. So far, it was really, really easy. But then:

I set up a signal generator (Owon DGE2070) for a rectangular signal 10.00000 Hz, Duty cycle 90%, High=3.300V, Low=0.000V, and connected to GPIO18. The outcome is terrible, as the pic shows:

The "measured" countrate is 61.7 Hz with Std.Dev=14%! This is over 6x of what the signal gen delivers, and fluctuates wildly. How comes?

My program - all done via HTTP - gets the counts with command 'cmnd=COUNTER1', then resets counter with comand 'cmnd=COUNTER1%200'. The cycle time is nominal 1 sec, but mostly about 5% slower. The counts are corrected for true cycle time.

Other setting:
SetOption159: == 0 --> falling edge
SetOption79: == 0 --> no reset at TelePeriod
TelePeriod: == 0 --> no messages

This is truly unexpected. What could be the cause?

[sfromis]

If you want stable timing, interfacing via http is likely the worst way, as you can expect network latency and blocking behavior + command processing in Tasmota (not a multithreaded system) to give too much "noise".

If you want to poll every second, use Berry. Using MQTT would already be better than http, but local programming with Berry (and without issuing Counter commands) is much preferable. The gpio module has API calls for interfacing with counters.

Doing a simple test with a Tasmota PWM gpio connected to a counter pin, I'm seeing stable ticks per 10-second TelePeriod interval.

For one-second polling, a Tasmota driver class with a every_second callback worked well with stable ticks per second. Using a cron timer was not quite as stable.

[ullix]

HTTP is not the culprit. I stopped all programs interacting with Tasmota by any means, and look at the Console. I let the counter run freely, without resetting, and issued TelePeriod 10. The signal generator was set at 1.000000 kHz. (It is stable; its jitter may be in the milliHertz region.) This is what the console showed:

21:49:56.977 RSL: SENSOR = {"Time":"2025-11-28T21:49:56","COUNTER":{"C1":48078}}
21:50:06.986 RSL: SENSOR = {"Time":"2025-11-28T21:50:06","COUNTER":{"C1":65548}}
21:50:16.993 RSL: SENSOR = {"Time":"2025-11-28T21:50:16","COUNTER":{"C1":82906}}
21:50:26.997 RSL: SENSOR = {"Time":"2025-11-28T21:50:26","COUNTER":{"C1":100456}}
21:50:36.997 RSL: SENSOR = {"Time":"2025-11-28T21:50:36","COUNTER":{"C1":118053}}
21:50:46.998 RSL: SENSOR = {"Time":"2025-11-28T21:50:46","COUNTER":{"C1":135691}}
21:50:56.000 RSL: SENSOR = {"Time":"2025-11-28T21:50:56","COUNTER":{"C1":153309}}
21:51:06.999 RSL: SENSOR = {"Time":"2025-11-28T21:51:06","COUNTER":{"C1":170798}}
21:51:16.998 RSL: SENSOR = {"Time":"2025-11-28T21:51:16","COUNTER":{"C1":188231}}
21:51:26.947 RSL: SENSOR = {"Time":"2025-11-28T21:51:26","COUNTER":{"C1":205656}}

The counts equate to an average of 1755 counts per second and a scatter from 1590 to 1960! It should be 1000 and a scatter of zero!

There is no HTTP involved.

[sfromis]

My testing giving very stable ticks was using a PWM pin to generate pulses. Maybe your signal generator setup has some sort of "electrical issues" causing the ESP32 pulse detection to jitter.

Of course, until having a test case with stable counts, you have no indication of whether using http is an additional factor.

[ullix]

Your mentioning of PWM gave me an idea. I compared the pulse rise/fall times, see pic:

My signal generator was MUCH slower than the ESP PWM. So, perhaps the ESP was bored during the long ramp times, and invented a few extra counts?

When I switched the Gen to square wave mode (with a fixed 50% duty cycle) its switching was much faster, and my counting gave the desired 1kHz! Hurrah! Alas, with a caveat:

On the right side you see the measurements. The average is 999.94. I'd say close enough to 1000 ;-).
On the left side you see frequency of occurence of each count rate, and it is odd that their are gaps of almost always exactly 50. This should not happen.

A question on the console log. On the status 10 command I get a log record, and its timestamp has millisec, while the json time stamp is full seconds only. Is there a reason for this, e.g. because it is synchronized for full sec? otherwise, can I have this record for time with millisec?

And finally, there is a "counter" and a "counter_n", as well as "PWM" and "PWM_n". The look the same. Are they different?

[sfromis]

The 50 ms steps fits nicely with the default Sleep command setting of 50 ms, combined with the totally expectable deviations due to using http. I'm not seeing this granularity with the recommended approach of handling the counter via Berry, but still getting better second-for-second stability with Sleep 0. Any other activity on the chip, including but not limited to things like Wifi handling and telemetry period reporting, can introduce jitter too.

AFAIK, the specifications for the ESP32 digital inputs does not include it processing signals as analog, and changing 0/1 state on a defined and stable millivolt level. Pulses should be pulses, and there are debounce settings to handle instability around switchover.

Counter_n means not enabling the weak internal pull-up of the ESP chips. There is no PWM_n, if you instead mean PWM_i, the _i suffix also available with some other component types means "inverted".

If you want milliseconds on the log timestamp too, the Time command has a setting to include this.

[ullix]

The millisec on the time stamp did the trick. Perhaps strange, but the difference between two subsequent timestamps gives the collection time of the counter. Then correcting my counts to 1 sec, i get this result:

You see from the "crumbs" on the magenta line that it is not perfect, but getting for a 100Hz signal an average of 100.000 with a Std.Dev of 0.2% is good enough. At least for now. So, I could demonstrate that a Geiger counter based on a vanilla Tasmota can work, and, as you initially promised, even without programming!

I hear you preaching "Berry", and I went through the intros. What is still not clear to me is how you integrate Berry into Tasmota. Do you have to include it in the compilation of Tasmota, or can you take a vanilla Tasmota, and "plug" Berry stuff into it? And if so, how and where do you do that?

[sfromis]

Vanilla ESP32 builds already includes Berry. What you can to is to create Berry program files in the local file system, and have it executed from there. You can then have a Berry call like load('counterticks.be') in the Berry console, or in autoexec.be to be done each boot. Here's a short piece of sample code handling a counter:

class CounterTicks
  def init()
    self.close()
    tasmota.add_driver(global.CounterTicks_instance := self)
  end
  def close()
    tasmota.remove_driver(global.CounterTicks_instance)
  end
  def every_second()
    var ct = gpio.counter_read(0)
    gpio.counter_set(0, 0)
    print('ticks', ct)
  end
end
ct = CounterTicks()

The thing with global.CounterTicks_instance allows for the driver to be added multiple times, with each test removing the previous iteration.

[ullix]

Thanks for the code. I managed to upload and execute it, and the console now shows like 16:03:13.973 ticks 52 in nicely consistent intervals!

But how can I read these ticks-lines into my Python program?

Is it possible to create this code within my Python code, and send it to Tasmota as a string? or as bytes? like I send 'status 10' for data?

[sfromis]

The Tasmota API for Berry includes things like creating your own commands, which can be executed the same way as native commands.

class CounterTicks
  var name, ticklist, tickentries
  def init()
    self.close()
    self.ticklist = []
    self.tickentries = 10
    self.name = classname(self)
    tasmota.add_driver(global.CounterTicks_instance := self)
    import json
    tasmota.add_cmd(self.name, /cmd,idx,payload ->
      tasmota.resp_cmnd(json.dump({self.name: self.ticklist})))
  end
  def close()
    tasmota.remove_driver(global.CounterTicks_instance)
    tasmota.remove_cmd(self.name)
  end
  def every_second()
    var ticks = gpio.counter_read(0)
    gpio.counter_set(0, 0)
    self.ticklist.insert(0, ticks)
    if size(self.ticklist) > self.tickentries
      self.ticklist.pop()
    end
  end
end
ticker = CounterTicks()

Now, command CounterTicks returns a list of the last 10 seconds.

[ullix]

That version is very helpful, thanks. It was then easy to add a data log file 'history.csv', which now sits in the flash storage. Great. My browser told me that I can download it with ' http://:80/ufsd?download=/history.csv'. Even better; amazing what Berry can do.

But documentation is a weak spot in Tasmota & Berry :-(. Hard to find answers. For example, to delete my History file it doesn't help to define a function and call it. As the class counterticks works so well, is it a MUST to always create classes, or are there simpler ways?

[sfromis]

Not sure where you looked about deleting a file, or what your trouble with it was. The path module does have a function to remove a file. https://tasmota.github.io/docs/Berry/#path-module
The Br command can be used to invoke any code bit, including such a function call, from outside of Berry.

You can do most things without creating a class; any Berry code (including a function definition) can simply be done outside of a class too, including longer one-liners (Berry does not need line breaks). The reason for my example code needing to have it in a class was that it adds itself as a driver, to get the very convenient every_second() callback. But therefore also having the cleanup with have a global variable with a reference to the latest iteration, if recreating the ticker during testing.

Without creating a driver, you could also use the cron feature for every second etc. And the Berry Cookbook page has a small example of using set_timer with a bit of extra logic to correct for any drift due to Tasmota also doing other things. Of course, this was added before the cron module provided a more generalized and stable API for repeating events.

Being experienced with coding, I tend to like the clean separation when coding with classes, but in simple cases it tends to be a matter of taste without big advantages. Of course, removing the command handler at the same time as the driver registration fits nicely with coding in a class already "knowing" how to clean itself up.

[ullix]

Life can be so easy onec you have the know-how ;-)

"Br" does the trick. My "Deletion of History" is now done with a simple file "delhist.be" with its content being solely:

import path
path.remove('history.csv')

and from Python I call this by: "http://:80/cm?cmnd=br%20load('delhist.be')". It works.

But once I have multiple such simple snippets, would I need a separate file for each? I'd rather have one file with multiple functions, and I call each function by name. I don't mind using a class with multiple methods. But then, how do I call each method?

[sfromis]

You don't even "need" a file for such snippets, as your case would work fine as a oneliner directly in the Br command. Of course, you could make a reasonable case for avoiding the details being spread to the Python code, but kept locally on the device.

You could do things like expanding the command handler from the posted sample code to pick up an argument for what to do instead of returning counter ticks. Or you could create separate command names for each, still having it all in one Berry code file.

[ullix]

Indeed, makes it simpler. I now use:

def reset():
    # in Python ...
    cmd = \
"""
br
import path
path.remove('history.csv')
return "nice"
"""
    cmd = cmd.replace(" ", "%20").replace("\n", "%0A")
    getUrlResponse(url, f"/cm?cmnd={cmd}")

# make cmd to: '%0Abr%0Aimport%20path%0Apath.remove('history.csv')%0Areturn%20"nice"%0A'
# and returns: {"Br":"nice"}

I am surprised that return "nice" actually returned "nice". I did not define any def. Or did I?

Could I do the same thing with you class counterTicks? Or would that require something else?

I wouldn't mind having all the code sitting in my Python code. Because then I wouldn't have to explain to the users how to upload Berry code to the ESP32 :-/.

[sfromis]

As Berry does not need line breaks, simpler: cmd = "br import path path.remove('history.csv') return 'nice'"
Oneliner code (as you created) is implicitly processed as an anonymous function, hence return allows you to provide a result value. Same as when you do things in the Berry console, where the result value is simply emitted to the output part.

I'm not doing much in Python, but I'd want to avoid coding URL encoding myself, instead using a function like urllib.parse.urlencode(cmd)

Not clear what you mean by "the same thing", but you can wrap anything you can do in the Berry console, or a loaded file, in a oneliner, as long as it does not get too long. Not sure what the limit is, but it is more than a few separate lines. Of course, separate steps for defining a class once only, and invocations. Berry does not "need" file system files, as long as you are not doing things like creating a module for use with doing a import, or of course using load.

Also: If you can provide a web server, the UrlFetch command, or tasmota.urlfetch function can be convenient to fetch files without user action.

[ullix]

I agree, it is mostly better to use the built-in fucntions. Here it would have to be: urllib.parse.quote_plus.

urllib.parse.quote_plus: '%0Abr%0Aimport+path%0Apath.remove%28%27history.csv%27%29%0Areturn+%22nice%22%0A'

manually replacing " " and LF : '%0Abr%0Aimport%20path%0Apath.remove('history.csv')%0Areturn%20"nice"%0A'

But so far the outcome from Berry is the same.

I am wondering what the function for filesize is? I can't find any, and my work around is to read the whole file and 'size()' its length. Is there really none?

[sfromis]

No need to read the whole file, just open it before using size()

[ullix]

My preference is to define the functions running on the ESP32 by sending those as http commands from Python, as "br xyz". And ran into the weirdest problems.

First, the url is http://10.0.0.104:80/cm?cmnd=MYCOMMAND, with MYCOMMAND being the Berry code (cleaned for chars like space and LF) to execute. I found out that the length of MYCOMMAND is strictly limited to be no more than 1199 characters! Perhaps some/all characters of cm?cmnd= also need to be added for the true limit number? Does that ring a bell of a some 1200 chars limit of urls for Tasmota?

When MYCOMMAND was your Counterticks code, this 1199 length was exceeded; so I shortened variable names, double-spaces and else. After that, I could upload to the ESP (without line numbers):

 1   class Counter
 2   var cpm, cps, name, tlist, tmax
 3   def init()
 4       self.close()
 5       self.tlist = []
 6       self.tmax = 60
 7       self.name = classname(self)
 8       self.cpm  = 0
 9       self.cps  = 0
10       gpio.counter_set(0, 0)
11   
12       tasmota.add_driver(global.Counter_instance := self)
13       import json
14       tasmota.add_cmd(self.name, /cmd,idx,payload ->
15       tasmota.resp_cmnd(json.dump({self.name: {"CPS" : self.cps, "CPM" : self.cpm}})))
16   end
17   
18   def close()
19       tasmota.remove_driver(global.Counter_instance)
20       tasmota.remove_cmd(self.name)
21   end
22   
23   def getCPM(cpslist)
24       var c = 0
25       for i: 0 .. (size(cpslist) - 1)
26           c += cpslist[i]
27           print(i, c)
28       end
29       return c
30   end
31   
32   def every_second()
33       var ticks = gpio.counter_read(0)
34       gpio.counter_set(0, 0)
35       self.cps = ticks
36       self.tlist.insert(0, ticks)
37       if size(self.tlist) > self.tmax
38           self.tlist.pop()
39       end
40       self.cpm = self.getCPM(self.tlist)
41       print(self.tlist)
42       print("CNT:", "cpm:", self.cpm, "cps:", self.cps)
43   
44   end
45   end
46   
47   ticker = Counter()
48   return "counter"

But I had the weirdest problems running it. The super-weirdest: Adding values from a list does not work!

I make a list of the last 60 CPS values, so the sum of it, done in def getCPM, is a CPM value. I rebooted the ESP, called Status, called Time ( to get milliseconds), and uploaded Counter. This is what Console showed:

00:00:00.001 HDW: ESP32-D0WD-V3 v3.0 
00:00:00.061 UFS: FlashFS mounted with 4384 kB free
00:00:00.073 CFG: Loaded from File, Count 222
00:00:00.082 QPC: Count 1
00:00:00.130 BRY: Berry initialized, RAM used 3766 bytes
00:00:00.142 Project tasmota - Tasmota Version 15.1.0(release-tasmota32)-3_3_0(2025-10-11T13:05:13)
00:00:00.259 BRY: Successfully loaded 'autoexec.be'
00:00:02.000 WIF: Connecting to AP1 fb75rw Channel 6 BSSId CC:CE:1E:7A:91:EA in mode HT40 as tasmota-E1E2F4-0756...
00:00:03.754 WIF: Connected
11:57:17.036 HTP: Web server active on tasmota-E1E2F4-0756 with IP address 10.0.0.104
11:57:18.020 RSL: INFO1 = {"Info1":{"Module":"ESP32-DevKit","Version":"15.1.0(release-tasmota32)","FallbackTopic":"cmnd/DVES_E1E2F4_fb/","GroupTopic":"cmnd/tasmotas/"}}
11:57:18.033 RSL: INFO2 = {"Info2":{"WebServerMode":"Admin","Hostname":"tasmota-E1E2F4-0756","IPAddress":"10.0.0.104","IP6Global":"","IP6Local":"fe80::7e9e:bdff:fee1:e2f4%st1"}}
11:57:18.045 RSL: INFO3 = {"Info3":{"RestartReason":"Vbat power on reset","BootCount":77}}
11:57:20.938 QPC: Reset
11:58:05.850 RSL: STATUS = {"Status":{"Module":1,"DeviceName":"Tasmota","FriendlyName":["Tasmota"],"Topic":"tasmota_E1E2F4","ButtonTopic":"0","Power":"1","PowerLock":"0","PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0,"InfoRetain":0,"StateRetain":0,"StatusRetain":0}}
11:58:05.915 RSL: RESULT = {"Time":"2025-12-07T11:58:05.914"}
11:58:05.990 RSL: RESULT = {"Br":"counter"}
11:58:06.922 0 38
11:58:06.923 [38]
11:58:06.923 CNT: cpm: 38 cps: 38
11:58:07.923 0 34
11:58:07.924 1 38
11:58:07.924 [34, 38]
11:58:07.925 CNT: cpm: 38 cps: 34
11:58:08.923 0 40
11:58:08.924 1 34
11:58:08.924 2 38
11:58:08.925 [40, 34, 38]
11:58:08.926 CNT: cpm: 38 cps: 40

Look at the last 5 lines: for the 3rd second getCPM walks through index 0, 1, 2 with CPS 40, 34, 38, yet returned as CPM is NOT the sum of it (=112), instead it is the oldest CPS recorded (=38)? Huh?

[ullix]

Correction: I missed that the "%" encoding actually makes 3 characters out of 1! So the limit for MYCOMMAND from above is 1593 characters. Looks more like a 1600ish limit?

[ullix]

To add to the weirdness, this is the code for getCPM:

def getCPM(cpslist)
    var cpm = 0
    var cps = 0
    for i: 0 .. (size(cpslist) - 1)
        cps  = cpslist[i]
        cpm += cps
        print(i, cps, cpm)
    end
    return cpm
end

If I replace cpm += cps with cpm = cpm + cps then Berry throws an error:

"Br": "[syntax_error] input:28: strict: expression without side effect detected"

Huh? Huh?

[sfromis]

In your "unusual" edge case intention of doing it all via Br commands, you should make extra sure that nothing is mangled from what you wanted to what you get executed on the device. Your experience with getting it to work when saving your code on the device also points in this direction.

And I literally meant what I already posted

as long as it does not get too long

to indicate that it is not "anything goes", but what fits as a command. Looks like you hit a limit, no surprises there ;-)

BTW. The list handling in Berry makes things a bit easier:

def getCPM(cpslist)
    var cpm = 0
    for cps : cpslist
        cpm += cps
        print(cps, cpm)
    end
    return cpm
end

[ullix]

When I save the very same Counter code to a file countercode.be, and then manually load that file into Tasmota, it is working correctly:

14:25:22.887 CMD: br load("countercode.be")
14:25:22.926 RSL: RESULT = {"Br":"true"}
14:25:22.958 0 0 0
14:25:22.959 [0]
14:25:22.960 CNT: cpm: 0 cps: 0
14:25:23.967 0 42 42
14:25:23.968 1 0 42
14:25:23.969 [42, 0]
14:25:23.969 CNT: cpm: 42 cps: 42
14:25:24.968 0 34 34
14:25:24.969 1 42 76
14:25:24.970 2 0 76
14:25:24.971 [34, 42, 0]
14:25:24.971 CNT: cpm: 76 cps: 34

The last 5 lines show that the sum of the last 3 CPS (34, 42, 0) is indeed the correct CPM (76)!

[ullix]

The catch here is what http thinks that legal character are. And '+' is one reserved for itself, it is used to replace a space character (but '%20' can also be used). So a '+' sign, when used to sum things up, must then also be '%'-encoded as '%2B'. With that, it all works!

Fortunately, the urllib.parse.quote_plus(cmd) does all that. Had I used it from the beginning ...

Google says all its url lengths are limited to 16.384 characters, as opposed to Tasmota Berry's 1600.

Thanks for the list handling tip! I have also discovered that Berry has f-strings :-). Nice!

[sfromis]

Well, I deliberately did not talk about URL length, but about command length, which you also should expect to apply when it is not part of a URL. 😉

Anyway, URL length does not have some sort of defined limit, but many sources suggest up to about 2 KB as reasonably safe cross-platform, but fields used in the URL can have their own restrictions, like Tasmota commands up to 1200 (not 1600), also in the console.

[ullix]

Is there a value of "nan" (Not-A-Number) in Berry? Like in Python with float("nan")?

[sfromis]

As you can read in the "short manual", you have math.nan, math,inf and nil
https://berry.readthedocs.io/en/latest/_static/berry_short_manual.pdf

[ullix]

I am basically finished with the conclusion that Tasmota is well qualified as a generic OS for Geiger counter! I am running it with real Geiger counter hardware. A more cosmetic item is left:

On defining an ESP32 pin as counter (I use GPIO22) the reading of the counter is shown in the WebUI. However, in present case the counter is reset every second, and the WebUI shows reading of anything from 0 to max CPS, as it is not synchronized. This is not helpful. Rather it is irritating.

I would like to either:

• not show any counter reading
• or, preferred, show last CPM, CPS, and the DateTime of that reading

The WebUI seems to update every 3 se, which is ok.

How can this be done?

[sfromis]

The command WebSensor is "Control display of sensor telemetry in the webUI"
The default WebRefresh interval is 2.345 seconds (not 3)

You might want to extend your driver with callbacks web_sensor and/or json_append to include your CPS/CPM data in the web UI and/or telemetry JSON data.
https://tasmota.github.io/docs/Berry/#creating-a-tasmota-driver
Example here (not only for I2C sensors)
https://tasmota.github.io/docs/Berry-Cookbook/#creating-an-i2c-driver

[ullix]

It is always amazing how simple things can be done! (Provided you ever find the info :-()

A question to 'import'. I am now doing "import string" in 2 different functions in my class. Is that necessary? Does it hurt/slow down anything? Is there any option to do it just once ?

[sfromis]

No downside to doing the import where needed, and it does have the upside of making code more robust to reuse and refactoring. While you can do things (like var, def or import) at a global level, making them available across code, I deliberately lean in the direction of a "best practice" of minimizing dependencies on things done from outside of a class, before it can work. This also works well if later wanting to package some feature as a module, tapp or extension.

[ullix]

Still struggling with the code. This is your original code posted above:

class CounterTicks
  var name, ticklist, tickentries
  def init()
    self.close()
    self.ticklist = []
    self.tickentries = 10
    self.name = classname(self)
    tasmota.add_driver(global.CounterTicks_instance := self)
    import json
    tasmota.add_cmd(self.name, /cmd,idx,payload ->
      tasmota.resp_cmnd(json.dump({self.name: self.ticklist})))
  end
  def close()
    tasmota.remove_driver(global.CounterTicks_instance)
    tasmota.remove_cmd(self.name)
  end

The init starts with self.close which I think means to remove the driver, if one is installed. But the next tasmota.remove_cmd(self.name) removes a command self.name, but at this point its value is nil, as it is defined only later. Does this make sense?

[sfromis]

You are right, the assignment of self.name should be before self.close()

[ullix]

Stuck again, this time at the template. Beginning with WebUI Configuration -> Template I can define the template. In my case I set GPIO22 to Counter, and save. Giving command 'template' I can see the newly made template, and can even send it from remote with
'Template {"NAME":"GeigerLog's","GPIO":[1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,1,352,1,0,1,1,1,0,0,0,0,1,1,1,1,1,0,0,1],"FLAG":0,"BASE":1}' (after encoding for web.

However, this seems to still need "Activation", and none of the template xyz commands do an activation, instead they all delete my configuration. Is that really possible only manualy on the WebUI?

[sfromis]

You can activate the template in 3 ways.

1. Select it in Configuration/Module, number 0
2. Module 0 is also a command
3. Tick the checkbox in Configuration/Other
   This is also where you can copy/paste the template around.