SHAC available memory reduces over time

given this was a keyword issue, I have not done anything further with this

 

Thank you @ssaunders we have made great progress.
I have deployed the new "MQTT send receive" and the "MQTT final" (with my firmware of 1.15.0). Everything appears to be working as it should.
out of interest how does the "MQTT final" event script get triggered by the "MQTT" keyword?
I have now created a separate user name for the SHAC to connect with the MQTT broker (in my HASS box) in the hope that it would reduce to processor load but it has not - so that issue remains.

 

In script properties. Event-based scripts can be associated with a single GA, or a bunch of GAs by using keyword. If execute during ramping is not set, then the script will only fire at the completion of any ramps.



Glad you found the AC keyword issue. I guess one would need to read the entire readme to even know that the MQTT send receive script looks at keywords 'MQTT', 'AC', and 'AT'. I might add a note near the top! Many would probably glaze over once they hit the Philips Hue section...

For your CPU issue I'd be happy to have a poke around. Will PM.

 

I've discovered this going on since restarting - might have been there before but seems to be chewing through memory and might be cpu user too....

 

What's in the error log, @philthedill?

 

it is blank

 

If there is no error being thrown, then I've no clue why you'd get 'Heartbeat initialised' spammed in the log, @philthedill. The script is restarting for some reason, and because resident/zero sleep it is restarting a lot.

Most odd. Right after that log message it enters an infinite loop, checking for heartbeat messages with a one second timeout, then rinse/repeat. It should never exit. But it clearly does.

Step 1: Change it to sleep 60 in the script parameters
Step 2: If it spams the log every minute instead, disable 'Heartbeat' for now, and we'll need to dig further.
Step 3: If it stops spamming the log, disable it temporarily and see if your CPU drops.

 

I think we are onto something - sleep 60 has the cpui/o down to .28 and falling - not seen for a long time!
However, it is still spamming once/minute and sending the usage up
I've now disabled heartbeat and seeing this

 

That looks to be absolutely brilliant, @philthedill, and what I would expect to see. Better than mine.

As to what's up with Heartbeat... who the heck knows?! It runs like a rock on my NAC. Latest code version installed?

 

I might not have update the heartbeat script - will now try that

 

done - will advise

 

looking good

i've loaded the heartbeat latest version and restarted with period set to 0 for send/receive and heartbeat with the following....
I'll check on the memory situation tomorrow

with even more thanks

Michael

 

this morning's reading:

 

this continues to work well but I have found a small snag. I am moving my operator interfaces from SHAC to HASS. In the process, I am keen to display the 2 SHAC unit parameters - alas without success. I have added <MQTT, sensor> to the keywords as follows:



everything looks normal and I can see the following in HASS - with measurement showing as <unknown>



any ideas please?

 

Ahh... Unit parameter...

Not something I have implemented. Give me some days before an update at https://github.com/autoSteve/acMqtt...

Will advise.

 

For Unit Parameters give the latest commit at autoSteve a try, @philthedill.

Treat the 'pn=' keyword as mandatory. Despite what the AC interface shows, these have no internal name that can be defaulted to. Use keywords like 'MQTT, sensor, pn=Voltage, dec=1, '.

I have noticed that updates to keywords were not carried through to HA for me for some weird reason. On a few occasions I needed to delete the homeassistant/ discovery topic for changes to show up in HA. The Mosquitto discovery topic had been updated perfectly well, just would not show the change in HA. Killing that discovery topic with MQTT Explorer and restarting the MQTT send receive script sorted things.

 

thanks for the follow up. I have done as you say a couple of times....the voltage parameter now appears in HASS okay. However, the utilisation has not. The name has come through but not the value....funny. I'll experiment further later on.

 

Huh. Same for me, @philthedill. I'll have another stare at it tomorrow.

 

No joy, @philthedill. I'm tipping that this may be an automation controller bug, or by design.

How about the following. Create two user parameters, AC Load and AC Memory (as floating point). Then this, a lightweight resident sleep 60 script:

Code:

data = io.readfile('/proc/meminfo')
load = io.readfile('/proc/loadavg'):split(' ')[ 1 ]

memtotal = data:match('MemTotal:%s+(%d+)')
memavail = data:match('MemAvailable:%s+(%d+)')
memusage = math.floor((memtotal - memavail) / memtotal * 1000) / 10

SetUserParam(0, 'AC Load', tonumber(load))
SetUserParam(0, 'AC Memory', memusage)

This will get the load and available memory (as a percentage) into the two user parameters.

Then tag the user params with MQTT, blah, blah... to get values into HA and you're away.

If you look at the load figures in the AC UI there are three shown at the bottom. The first would be a one minute average, the second a five, and the third a fifteen. So to change the script to get the fifteen minute average, use [ 3 ] instead of [ 1 ] in the code.

The /proc/loadavg 'file' returns a string that looks like "0.16 0.28 0.25 2/64 2040". The first three numbers I've explained. The rest you don't want. The x/xx is the number of currently executing kernel scheduling entities plus the number of kernel scheduling entities that currently exist on the system. The number at the end is the process ID that was most recently created on the system. Yeah, you don't care.

To interpret the load number you're seeing, head on over to https://www.tecmint.com/understand-linux-load-averages-and-monitor-performance/. Nerd alert. In English: Low number? You paid too much for your CPUs. High number? You might want more, which you can't have.