Rounding values in Berry for use in Haspmota

[valdus2]

As I've read, Haspmota uses int. To have better results, now I use the below for rounding the values:

def BME(topic, idx, payload, bindata)
var sensorvalues = json.load(payload)
var temp = sensorvalues.find('BME280', {}).find('Temperature', 'missing temperature')

var n = (temp - math.floor(temp) > 0.5) ? math.ceil(temp) : math.floor(temp);

global.p12b33.val = int(n)
end
mqtt.subscribe("tele/ESPmeteo_588C02/SENSOR", BME)

Is there a better way for doing this? Or maybe there is a way to pass floats, doubles to Haspmota val, from Berry?

Irrelevant: Is there a limit to how many subcribes we do in berry? Can it handle 100-200 subscriptions for example?

[barbudor]

That's over complicated

var n = math.floor(temp + 0.5)

[s-hadinger]

That's a good point. HASPmota takes only integers indeed, but we had never the case of floating point before. I can add this automatic rounding in HASPmota code

[valdus2]

That's over complicated

var n = math.floor(temp + 0.5)

With this it doesn't work OK....

That's a good point. HASPmota takes only integers indeed, but we had never the case of floating point before. I can add this automatic rounding in HASPmota code

Yes, for example 29.9C is 30C not 29C....

[valdus2]

S-hadinger, how did he implemented in development branch? With what equation?

[barbudor]

Exactly how I wrote it

Tasmota/lib/libesp32_lvgl/lv_haspmota/src/embedded/lv_haspmota.be

Lines 1022 to 1025 in 01140d3

	if type(v) == 'real'
	import math
	v = math.floor(v + 0.5)
	end

[barbudor]

math has generally not much to do with human consideration or surprise

the "principle of least surprise" would be that the numbers are rounded as if they were positive

With such consideration you expect the integer part of -0.5 to be 0 while it is -1

[valdus2]

You're making me feel really bad now....I don't wanna see you arguing...
There are bigger problems in our lifes from the "0.5" math problem.....
At least, anyone can implement it the way is better for what he/she wants to achieve.....

[sfromis]

No, as long as I expect 0.5 to round to 1, I'd also expect -0.5 to round to -1. That's the principle of least surprise. I would certainly not think like "the integer part of -0.5", as rounding is not about the integer part, but about conventions for reducing number of decimals.

Moving the decimal point (to avoid the complication of thinking in "integer parts"), I'd say that 0.05 rounded to 1 decimal should be 0.1, and therefore rounding -0.05 to 1 decimal resulting in -0.1. Would you think that 0.0 wound be the appropriate rounding for that?

I'd say that "real" rounding is about a selected number of decimals, where 0 decimals is merely a special case. Both math.floor and math.ceil is about handling of that special case in a way which just does not care about what rounding is.

To be clear, these consideration apply to the case of displaying values for human consumption, like when using HASPmota. I'm aware that for the different purpose of using the data for statistics after the reduction of number of decimals, the biasing caused by rounding away from zero, instead of "rounding" in the same direction may be a detrimental issue.

And don't worry valdus2, a bit of friendly comparison of opinions is not bad....

[s-hadinger]

It's now in development branch

[valdus2]

Sfromis, what do you mean by "...structuring for using wildcards." ?

I don't mean a ton of messages all at once but a small number of messages at random teleperiod times,
But, the subscriptions quantity as a number does present a problem?
As s-hadinger said about memory consumption, I used 30 subscribes and I didn't see a significant change in free memory....(ESP32-S3)

[sfromis]

What I mean is that if you use the default Tasmota topic structure of tele/tasmotadevice/SENSOR, you can get all devices by subscribing to tele/+/SENSOR, or all from one device by subscribing to +/tasmotadevice/#. Likewise with other topic structures where + is wildcard for one level, and # for a prefix subscription. In many cases, you can plan the topic structure to work will with wildcards.

And a high number of individual subscribes does increase the processing time to check each message. While the memory overhead may not be huge, if you are using a device without PSRAM, and have 200 subscriptions with long topics, it does add up, if you also have many other things you want to fit in.

[valdus2]

OK, got it....To reduce processing time I have to use wildcards for messages.
Because this is something new for me, could you please be kind enough, to share an example, how could I access every separate topic?
So, the below example could become what for every sensor (temp,hum,press) using wildcards?

def BME(topic, idx, payload, bindata)
var sensorvalues = json.load(payload)
var temp = sensorvalues.find('BME280', {}).find('Temperature', 'missing')
var hum = sensorvalues.find('BME280', {}).find('Humidity', 'missing')
var press = sensorvalues.find('BME280', {}).find('Pressure', 'missing')
blah, blah
end
mqtt.subscribe("tele/ESPmeteo_588C02/SENSOR", BME)

[sfromis]

Well, if you want all devices, my example was tele/+/SENSOR which also gives you payloads from devices not having the relevant sensor, meaning that if sensorvalues does not contain the BME280 object you can skip it. But it may be a question of what poison you want to pick. If your subscription gets you a lot of payloads from devices you do not want, that may be a higher cost than having many subscriptions. Thus there is absolutely no have to use wildcards, just an option which in some cases may be preferable.

However, I do have an ESP32 subscribing to SENSOR payloads from well over 100 Tasmota devices, which is not a problem. On average, with a 300-second TelePeriod, that's still a lot less than 1 message a second. No sweat. My reminder of the potential for a high workload was if you'd get a firehose of messages a second, which usually does not apply if it merely is SENSOR telemetry messages.

But if you are at the scale of having a huge number of devices pushing messages at a combined high rate, that's where you need to be careful, and also consider if an ESP32 is the right device for handling all that.

The short version ... If it is "only" less than 200 devices with telemetry period 5 minutes, that should not be a problem, unless maybe you have them all synchronized to the exact same time to publish.

[valdus2]

"...what poison you want to pick..." OK that made me really lough ;-)
I belong to the first category using just telemetry messages, not only from tasmotas but a whole bunch of different devices.

"...have them all synchronized to the exact same time to publish..."
Now that would be a mad's man(programmer) job !!!!!

Everything is fine then.

Thank you and my respects to ALL !