How can i import a class ?

[NiklausS]

maybe a silly question - but i don't get it.
when i creat the file:
/tmp117.be
and add in the autoexec.be the line

load("tmp117.be")

tmp = TMP117()
tasmota.add_driver(tmp117)

this failes with:
00:00:02.609 BRY: failed to load '/autoexec.be' (syntax_error - /autoexec.be:45: 'TMP117' undeclared (first use in this function))
tried different ways but not luck so far. Also in the docs is no specific information. As long as everything is in the same file it works fine. But having lv code and drivers all in the same file is getting ugly.

i would like in the end to have on file with the display desctiption, getting the values from the different drivers like print( tmp.read_temperature() ).

[sfromis]

In your specific case, the simplest would be to do a var TMP117 before the load; that way you have the symbol defined for the compile step, with the class only becoming available in the separate runtime step, where the load is executed, and the code in the file is also compiled (or loaded from the .bec file).

More generally, import is for a module, not just a class, but you could wrap a class in a module, to return a class instance for later use.

When it comes to getting temperatures from the TMP117 driver, you do not actually need to call a method in the class for that. Assuming that you did not change it significantly, the values are also available (along with other sensors) if you

import json
var sensors = json.load(tasmota.read_sensors())

Of course, this may be a bit problematic if you are also creating a driver supplying data to the same sensor payload, as your json_append() will also be called when you tasmota.read_sensors.

[NiklausS]

Thanks for this. So if i would like to work with multiple driver files i would do it this in the following way - or is this conceptually wrong?

autoexec.be

import string
import ina226
import ina3221
load("main.be")

main.be

ina3221 = INA3221()
ina226 = INA226()
print("loaded...")

def rule_temp(value)
  print("The temp is ", str(value))
  print("The V shunt1 is ", str(ina226.read_Vshunt()))
  print("The V shunt2 is ", str(ina3221.read_Vshunt()))
#   bmp280.set_text("Temp=" + str(value) + "°")
#   Vshunt.set_text(string.format("Vs=%2.3fmV", ina226.read_Vshunt()*1000))
end

tasmota.add_rule("BMP280#Temperature<27.3", rule_temp )

ina3221.be

import math
class INA3221
    var Vshunt
    def init() print("I2C: ina3332 detected on bus ")   end
    def read_Vshunt() return math.rand(2) end
end

ina226.be

class INA226
    var Vshunt1
    def init() print("I2C: ina221 detected on bus ")   end
    def read_Vshunt() return math.rand(2) end
end

[s-hadinger]

Each file imported must return an object, generally a module or a class. Here you don't return anything

[s-hadinger]

https://github.com/berry-lang/berry/wiki/Chapter-8#83-how-to-package-a-module

[sfromis]

The technique with defining a var first was for doing load (like in what you posted as example of getting an error), not when doing a bad import of something which is not even a module.

Sure you can package it as modules, which is a bit more cumbersome, but can be useful for doing import inside of classes, where you can always get the same module instance by doing import. But this is not much different from what you can get using load and having a global variable.

Where using modules have their strong point is not by treating it as a mechanism to load a class by doing import instead of load, but when you can package something in a nice way to have the module being easier to work with, like to create instances or be encapsulating a feature without having all the innards exposed outside of the module. Can also reduce risk of naming conflicts.

If you do the simple load of a file with a class, you could adopt the convention of always explictly prefixing global variables with global. - This provides easier understandability of the code, and then you do not have to make "weird" var defs first.

Like having

load('ina226.be')
global.ina226 = INA226()

When later using global.ina226, the Berry compiler no longer has the expectation of having the symbol already defined at compile time. And you could chose to put the global.ina226 = INA226() inside the file, and you'd still not get compile errors when referring to global.ina226. It will just be nil if nothing was assigned, or you make a typo in the name.

One downside of doing a load of a file is that this should only be done once, while packaging as modules and using import does give the flexibility of it working with doing the import wherever relevant.

[Staars]

Is this module cache constantly growing with every imported module or is there any kind of memory management to prevent this?

[sfromis]

I don't see any "memory cache" around modules, not sure what you specifically mean by using those words. But don't expect modules to be un-imported somehow. What you get is more like making an extension to Berry available, and then the module can have some internal memory management for resources it allocates, like if you have the module contain class instances with instance variables.

[Staars]

Following the link above:
…
There is a global cache of all modules already imported. If was already imported, import returns the value in cache already returned by the first call to import. No other actions are taken.
…

[sfromis]

If you are aiming for having things loaded temporarily, to be garbage collected after use ceased, stuffing it in a module is not the way to go.

[Staars]

That is exactly what I am doing right now - avoiding (self created) modules.

@s-hadinger For my understanding: Is it pointless to import a locally import a module in terms of memory management? So it would be easiest to simply globally import all needed modules (per file)?

[sfromis]

Well, there is no memory management benefit from using global imports, hence this is for me no reason for the code smell of relying on using globals, outside of for state meant to be kept updated for the whole runtime. Note that I'm not saying that it is "very bad" doing global imports, just not something I see as "best practice".

Hence I see a good point in consistently doing local import, and making globals per file is not very "clean" either. But I do have some leaning towards purism....

And I very much like using self-created modules, as this provides a good and simple encapsulation, with neat units which can be imported where relevant. I do not see a Tasmota environment as a system where the code present is dynamically swapped during runtime, to me it sounds like you need PSRAM.

[s-hadinger]

Local or global imports don't really make a difference. Global imports tend to pollute the global namespace, that's the only difference

[sfromis]

Yes, that's the "code smell" I mentioned.