Having the same issue.
-same deal. I’m at 96%. However, I’ve got another memory monitor going and it only shows 24%. Hmmm…
Hi, similar problem here seems that the myDevice.pid is eating up the memory and CPU. Can anyone tell us how the system works? The documentation gives no indication of the technical details of how the system works. However, i can make a guess and say that the code running resident in memory is constantly scanning for GPIO changes and also always checking for user changes. Hence the heavy usage of CPU and memory… Maybe a user defined time parameters to set the time interval would help. Splitting the two processors would also help as they would not need to be resident in memory for any length of time… just a thought…
Hi @Martin4, and welcome.
For everybody following this thread, I want to apologize for the delay in getting this issue fixed, and thank you for your patience. As mentioned above, we’re aware of the bug - it was just a matter of pulling some of our development resources that have been focused on enterprise features to fix some of these long standing issues raised in the community. We met about it yesterday with management and are getting a committed developer just to work on the issues raised here, and this one is #1 on the list.
I’ll update here as soon as there is any change on it – I’m confident we’re talking in terms of days or weeks here rather than months.
1 Like
I’m still seeing this bug and It eventually hangs the pi, does cayenne have any logs I could look into to see why?
Hi @ifload,
We do have a log at /var/log/myDevices.log but I don’t think its anything related to your specific configuration that you’re going to be able to change based on the log output. Ultimately it is an across the board issue with our Raspberry Pi agent software that will need to be fixed in an upcoming release.
The best workaround until we have that fix out the door might be scheduling a daily reboot of the Pi with the Cayenne Scheduler in order to free up used RAM.