The 1.1.2 resulted in the not found status… now with 1.1.3 it just return a white screen with no return at all.
// Ted
reverted.
Try 1.1.4
1 Like
Thanks. Back to working again. As I say, very happy to help testing with experimental versions. I’m not a developer so can’t offer more practical help. Have sent you a donation to thank you for your ongoing work on the app though.
Thank you @Jonathan_Draper .
Can you test that version (1.1.4)? In the next beta version I want to try a different approach, but testing with a real case like yours it’s better.
Now I’m reading some documentation, because I want to understand what’s going wrong with that code.
Paolo
1 Like
Hi, what kind of homey are you using?
(The “old one” like mine or the new version?)
HP2023. It works on the old once i have.
Yes have been using 1.1.4 for past 3 days now. I have tweaked my dashboard design so that it now only refreshes (and therefore sends an API request to Local API) once a minute (except when someone interacts with it when it sends other requests too). I have also been keeping the memory leak under control by having a flow restart the Local API app every 2 hours. By doing this, the app is very responsive and doesn’t eat too much memory before it gets restarted each time so keeps everything stable.
When previously I had the dashboard index page refreshing more frequently (every 10s) then it was eating up memory a LOT faster so it’s clearly some memory usage with each API call that’s building up. The API requests I am sending return a JSON structure containing 22 values from various variables / device statuses - so not a large amount of data each time. Not sure whether that’s related to the problem anyway.
Here’s a screenshot showing most recent 24 hours of memory usage for Local API app where you can clearly see the 2 hourly restarts. Overnight it was very smooth then this morning there was more interaction with it so a bit more variable.
Also noticed this - interestingly there are some occasions when the app does clear up some memory usage when not being restarted. The first and last large drops here were restarts; the two smaller drops in the middle weren’t. Also, the reduction in memory usage on each restart isn’t the same.
Ok, some updates:
1 -
for all those who have the new version of homey:
Unfortunately I don’t have a new device, so I can’t conduct tests and developments directly.
At the moment the error I get is directly dependent on homey’s API.
Error: Circular Reference "socket"
at walk (/node_modules/@athombv/homey-serializer/src/traverse.js:24:40)
Unfortunately, I can’t touch the homey-serializer API/module in any way, so I’m forced to wait for the Homey developers to do something about it.
2 -
@Jonathan_Draper first of all thanks for the support and useful information.
The size of the JSON could actually make it worse. In the graphs, those little decreases in occupied memory are due to the javascript garbage collector (which intervenes autonomously).
Can I ask you to share with me the screenshot of the flow , and if possible a complete example of the generated JSON?
I’m still reading some possible solutions to this problem, then I’d like to try to make a test version available for download (I’ll leave the link here in the forum) I’d ask you if you could try that too and give feedback about it.
Sorry if I’m not very responsive, I try to do everything possible!
It sounds like you’re trying to store an instance of something (HTTP request/response?) as a setting, which can only store plain objects. Is that the full stack trace?
Hi @robertklep here is the complete stack-trace:
Error: Circular Reference "socket"
at walk (/node_modules/@athombv/homey-serializer/src/traverse.js:24:40)
at walk (/node_modules/@athombv/homey-serializer/src/traverse.js:32:23)
at walk (/node_modules/@athombv/homey-serializer/src/traverse.js:32:23)
at walk (/node_modules/@athombv/homey-serializer/src/traverse.js:32:23)
at walk (/node_modules/@athombv/homey-serializer/src/traverse.js:32:23)
at walk (/node_modules/@athombv/homey-serializer/src/traverse.js:32:23)
at traverse (/node_modules/@athombv/homey-serializer/src/traverse.js:42:10)
at HomeySerializer.serialize (/node_modules/@athombv/homey-serializer/src/index.js:136:12)
at /node_modules/@athombv/homey-apps-sdk-v3/lib/HomeyClient.js:51:32
at new Promise (<anonymous>)
If you can help, any PR on the code is welcome, here ( GitHub - ilpaolino/homeylocalapi ) you find the sources, in order to check what is done at the application level
Do you know when exactly the issue occurs?
No, sorry, there is nowhere where it highlights in the app that help me to identify where the error is raised.
Additionally I can’t try the code in the new Homey (2023), so I can’t try to identify where the errors occurs.
If anyone had any idea, is appreciated.
Then do you know if the issue occur for every HP2023 user? Random “strange” errors are a fact of life and don’t necessarily mean they are related to your app.
Hi @ilpaolino - thanks for your ongoing efforts. Happy to keep testing and providing what info you need. I attach a screenshot of the flow for the request that gets fired every minute from my dashboard. There are some other requests from the dashboard as well but only in response to button clicks so almost all of the traffic is this one request.
The JSON response looks like this:
{
"status": "success",
"url": "/dashboard/homepage",
"method": "GET",
"data": {
"sunrise": "06:40",
"sunset": "19:31",
"today_min": "9.4",
"today_max": "10.3",
"feels_like": "9.3",
"wind_speed": "33",
"weather_condition": "Drizzly",
"current_temp": "10.2",
"inside_temp": "18.5",
"downstairs_secure": "true",
"house_secure": "false",
"jon_home": "true",
"xxxx_home": "true",
"xxxx_home": "true",
"xxxx_home": "true",
"xxxx_home": "false",
"house_state": "Day",
"term_time": "true",
"holiday_mode": "false",
"today_weather": "300",
"bin_day": "neither",
"milk": "false"
}
}
I’ll happily try a new test version whenever it’s ready.
This is the issue:
requestReceivedTrigger.trigger({}, { request: req, response: res });
req and res cannot be serialized, which is causing the error (I guess that the way triggers are handled differs between HP2019 and HP2023).
To fix this, you should only pass the properties of req and res that are required (and make sure that these properties are either scalar or just plain arrays/objects that don’t contain any instances).
1 Like
Thank you @robertklep
I will try over the weekend to integrate this solution and put it in beta.
Thanks for your help
Here in beta the last version with the @robertklep solution.
@Jonathan_Draper @Teddy
Let me know if this version is better.
Thank you all
Paolo
2 Likes
Good morning Paolo
It works for me on my HP2023 now 
I had one of my flows that i had to recreate for some odd reason it didnt work. It seam to have been in relation to the Respons flow card for JSON return. But after recreating specificly that card it worked. The rest worked without problems after install.
Thank you for this! I have it in testing now on my HP2019. Early signs are good on memory usage too but I will keep an eye on it over the next few hours and report back.
