Llocal variable connector is not working correct after 2.2.5.130 update

Physically could be enough at 10 minutes, first I set a 10 seconds interval between interrogation, after I seen the message I made the setup for 30 seconds and I still have severe load. This load is on the spot, I think where the calculation are done it is like a spike on the CPU load, the even I rise the time gap between calculations run, I will have also this spike and the message.

Why not trigger based on one (or more) temperature sensors changing in temperature? That will make for a much less CPU-intensive rule.

2 Likes

Now I see there is not a hardware problem, but due to my curiosity I check a software sequence optimization for a smallest resource use. I try to do all as easy as I can...

1 Like

Yes I tried already... but if I don't force the question to the sensor this will not send me the data so often as I need. Some time if I don't ask it it will send me data over half hour or later

I'm confused by this. The sensor will send data anytime there is an event change. Meaning, any time there is a temperature change. Querying it more frequently will not increase the frequency of temperature changes.

2 Likes

no, it is not sending the data all the times. Some time it will do that when it register some change, some time will not do... Could be sensor problem, but I have 5 of them and all are doing that. they are zigbee from Blitzwolf designed for tuya.

Not a sensor issue. Most probably it is a zigbee mesh issue. How strong is your zigbee mesh? Can you add some zigbee 3.0 outlets to strengthen your mesh? They will work well with the blitzwolf sensors.

One of my zigbee meshes has about 60 end-devices, for which I have 14 plugs as repeaters. A good ratio (from what I've read) is one repeater for every 6-8 end-devices (like sensors).

https://docs.hubitat.com/index.php?title=How_to_Build_a_Solid_Zigbee_Mesh

2 Likes

Is it this one?
image
If so, what driver are you using.

1 Like

I have 10 Ikeea outlets, all around (they have mesh amplifier integrated).
First when I designed the logic and test it, the sensors they was 1,5 meters away from the hub :frowning:

1 Like

What I would say is that each trigger of the handler is running for about 1.3 seconds - that's a lot of time and the reason for the high CPU usage. triggering every 30secs isn't the issue.

I load test MQTT against several triggers per second and in typical use 24/7 it runs happily in my system at a loading of once every second but I process (quite intensively) on one core in just 60mS . That 1300mS is really the culprit multiplied by every sensor. You could reverse that by almost an order of magnitude by time triggering every 30 seconds and check each within that single loop rather than 8+ individual sensors but above all reduce that 1.3 seconds process time.

I don't think the hub update is relevant - it's just drawing your attention to an existing issue.

1 Like

This is it; I have downloaded the Konkee ZigBee Teperature Humidity Sensor

OK. That is the one I am using and getting no issues with my 2 sensors.
I just wondered in case you were using a different one and I was going to suggest using the Konke driver to see if things improved.

1 Like

Thank you... Do you use the data from the sensor as described, it send the data at every change immediately?

I'm using it for humidity readings in my bathrooms. If above a certain level exhaust fan comes on, below, fan turns off.
They seem to change to the new humidity and temperature in around a minute at the worst.

As I'm using it for humidity though, this will give big changes when the shower turns on/off.

1 Like

So my sensors have some problems? hmm but al 5 ? something is wrong. I need to check again, I collect some info and update the topic...

I may have misled you here.
I'm talking about when the shower turns on.
Then, as there is a big change in humidity and temp, they both change within a minute.
Under normal circumstances the changes are not very often as the temperature and humidity remain pretty constant.

What could be an option is if someone could post some code that would be needed to allow a refresh of the device.
Then you could write a rule to do a custom action to refresh the devices every 15 minutes maybe.

Anyone out there know what is needed?

1 Like

Yeah I edited a driver to do this every 5 mins. I'll dig it out and update the post.

under metadata before fingerprint make sure there is this

capability "Refresh"

under preferences add this

input name: "PollEnable", type: "bool", title: "Enable poll of temperature", defaultValue: false

under the updated () function add this

if (PollEnable) schedule("$secs $mins/5 * 1/1 * ? *", refresh)

that will poll a random every 5 mins (stops them all polling at exact same time) you can change the 5 to another number like 10.

Try it, there is another reference to refresh in the code but its not being called by it.

then it will give you a option to enable the poll and when you save it will set up a schedule.

2 Likes

Hi @BorrisTheCat
First of all, thanks for doing this, much appreciated.
Unfortunately it is not defining a schedule and I am seeing this error in the logs which refers to this line of code that I inserted.
I had enabled polling and saved preferences.

dev:77112021-02-04 16:51:50.187 errorjava.lang.IllegalArgumentException: Name cannot be null. on line 171 (updated)

if (PollEnable) schedule("$secs $mins/5 * 1/1 * ? *", refresh)

Here is how the full section of code ended up.
Hope I've done it correct.

// updated() will run every time user saves preferences
def updated() {
	displayInfoLog("Updating preference settings")
	init()
	if (lastCheckinEnable)
		displayInfoLog("Last checkin events enabled")
	displayInfoLog("Info message logging enabled")
	displayDebugLog("Debug message logging enabled")
    if (PollEnable) schedule("$secs $mins/5 * 1/1 * ? *", refresh)
}

Just incase move it to just under the update before the init() function.

Did you add the other stuff?

Send me the code aswell probably be easier.

I managed to change the triggers from time schedules to other events, but not temperature changing only. It is ok now, the load is much low. The severe load was coming from high rate of the rule execution, not from the triggers.

1 Like