The frequency the data comes from the Dutch smartmeter cannot be changed. However, in the settings you can set the Update Frequency. The plugin will ignore the in between updates and this reduces the load of the plugin a bit. However, I had this running on a Vera Lite with other plugins without any reloads, so not sure it is the cause.
Also check your internet connection. Check your modems logs as some ISPs do funny things at set times as they think all we do is browse between 17:00 and 23:00.
If you ever have the will and opportunity to move from Reactor for Vera over to MSR**, even for part of your workflow, you can pull in all that data natively instead of having to use the Site Sensor plug-in. Marvelous as it is, a plug-in is a plug-in, and anything running on Vera that can be done by other means is - as we all know - less than optimal.
EDIT: Turns out that Reactor can send/process HTTP requests natively as well. See responses below.
No need to move to MSR, as Reactor for Vera has the same ability to make an HTTP(S) Request, store the result, and use other expressions to extract the results and do things with them. So that would be an alternate way to tackle this problem without adding more hardware and software.
@MPDomotica I will be curious to see if you putting a delay between those two activations of SiteSensor helps.
This morning no luup reload around 6:50 so this seems ho have helped.
But this afternoon I saw again 3 luup reloads. Because of the short logs rotation cycle I cannot see what happened around those times.
Question: what can I do to free up memory on this Vera Edge. On my “Master” Vera Edge with 60 zwave nodes, quite some Reactor Sensors, Hue plugin etc I have 3.5M available memory in rootfs (63%) on this Vera Edge only 1.2M (88%).
In the directory /etc/cmh-ludl I see some Sonos png files. Should they be here ?
Ah… OK. If you are building strings from the weather information to be spoken, you should make sure to set the UseCache parameter in those TTS actions to 0, so the speech is not cached. It’s not useful to cache speech that cannot be repeated: it just wastes disk space. So, I suspect part of the consumption is your TTS cache filling with non-repeatable speech audio.
After you fix your TTS actions, run the following command on your Edge:
rm -rf /www/sonos/ttscache
Then check space and see how much that freed up.
Caching is intended to make repeated spoken phrases more reliable and faster. If a phrase is in the cache, it will be spoken from the cache, instead of going out to Azure or whatever service you are using to build and fetch a new audio file. But if the phrase is different every day, there’s little value in that.
You can also shorten the cache life by setting TTSCacheMaxAge on the Sonos plugin’s master device to a number of days. The default is 30.
I had already put UseCache on “0” a long while ago, but had the impression it still used the cache. I did not remove the cache files. So I used your command and now the available memory in rootfs went up from 1.2 to 1.9 M ((80% used).
In the directory www/sonos I see some files with the name “say…mp” Screenshot:
Hi Rene, I already have found your new plugin and testing it on my “Test-Vera”.
I have my own Personal Weather Station uploading data to WU so obviously I want to keep on using mu own local data. Do you think it makes a differences in load on my Vera if I would use your plugin in stead of doing it via Site Sensor as I do now?
I’m now testing Buienradar via your plugin mainly because of the radiation intensity it provides. This is in Watt/m2. I use Reactor expressions to calculate the radiation sum in Joule/cm2. These data are from an official weather station in my region and it works quite well: data seems accurate. I want to use the radiation sum to automise my sprinkler system furhter (I use OpenSprinkler plugin for this). But this is off topic here…
I don’t think you’ve said what firmware you’re on, or at least, I can’t find it mentioned in the discussion here easily, so… what is that? Found it! 7.32 beta 4 now, right?
