Perhaps you can find out which cards cause this and share the flow with me, that would help a lott!
Well, does it work correct with ADvanced flows?
Because i cannot simulate this, no matter what i try.
Default flows or advanced, no matter what i try, it works as expected when i test it.
I donāt understand anything anymore.
I just installed v.13.2 again after updating to the Homey firmware v10.0.0-rc.110.
So far v.13.2 is running and has not crashed again. Iāll keep an eye on it and get back to you. Maybe the diagnostic report will be of some use to you:
4099420a-ce12-4657-a662-765f965f5b11
Edit:
Maybe I can put you on the right track.
I just restarted Homey and v.13.2 crashed again. I noticed that the app was using 79 MB of memory. Homey only had 18% free RAM at this point. I deactivated v.13.2 and restarted Homey.
I then waited until Homey had started all the apps and only then reactivated v.13.2.
This worked and the app runs.
Is it possible that the app is crashing due to a lack of RAM in Homey?
Now everything seems to be normal. I will probably install the computer module 4 with 8 GB RAM again.
1 Like
I just realized, with this card, a lot of timer flows for switching light off after 5 minutes, can become useless.
You would now only need one of the amentioned flowcard, and watch for a motionsensor being off for, f.i 5 minutes and then turn the light off.
No more need for multiple timer flowcards 
2 Likes
No m8, your app was crashing because the app.json was from version 2.11.11, and thus missing the new flowcards.
But the app.js (the code) was from >2.12.0.
Thus, the app tryed to start the new flowcards, but the could be found.
Thats why i opened a ticket on slack with Athom, because this was a known issue way back with the hp2023, and it was suppose to be solved.
Somehow the bug is back, that the app.json was not overriden during the app update to the test version.
Sorry, didnāt notice you writing this.
Thats straings, i did not get a crash report. Also in the developement portal, there is no crashreport for v2.13.2.
If the app was using 79MB and then it crashed, it was very likely killed because of the 80MB-per-app limit that the SDK imposes. You donāt get crash reports for those.
Ah thanks Robert.
And thats a shame, perhaps the crash report would have shown why the memory was that high.
It wouldnāt, the SDK just looks at the total amount of RAM an app uses and kills it if itās too high.
And how much memory was it using then/now?
Because this does give me a clue where the memory leak is.
Unfortunantly, the solve would be in using the new homey-api. And that will take some time and im waiting for v3 to be working correctly (insights do not handle the resolution correctly, and i use that in multiple flowcards).
Yeah, but i do have some logging, and if a certain line i expect is there to much, that āloadingā line would probably indicate thats the leak.
Perhaps you could trigger a crash in your app at 79MB RAM usage, right before the SDK would kill it, so youāll receive a more useful crash report for it?
1 Like
HP2019 v2.13.2
Something weird happened. My AVD device broke, when I updated Textfield 5 (I removed a reflect in order to update the text field in a flow).
Broken fields:
Numberfield 1 (Temperature now), Numberfield 2 (Temperature min) and Numberfield 18 (Temperature max) disappeared from the flows where they were used. None of these are using reflect.
I also lost the ability to select flow cards for āTemperature Now becomes less than/becomes greater thanā. They do not appear anymore.
Browser refresh or restarting the DC app did not help.
What else can I do to fix the numberfields?
Iād love to, Arie, but Iām just at the point when I started to notice this behaviour.
I will try to record what I was doing / what was happening when the memory runs out.
Thatās weird, those cards are default homey cards, but they could only exists if you have the checkbox on for Create Flow Cards.
That option is only suppose to be available for any number ShowAs, except the Sensor(default) en now the Sensor (status).
Were they not another ShowAs type before? (the Numberfields i mean)
Okay, i found a change i did, hang on, iāll fix this.
1 Like
Okay, this is solved: you need to recheck the Create Flow Cards for these fields.
And, i fill like an ***, but i just removed the new ShowAs Sensor (Status).
Because you can just put it to Sensor (Default) and check the Create Flow Cards: THen itās also able to be selected as status indicator.
So, to save about 300 lines in the app.json, i removed the Sensor (Status) (because it was with icons, itās a lott of double capabilities.
So for anyone why has created Numberfields with Sensor (Status), goto device repair, selecct Sensor(Default) and check the Create FlowCards, and than reselect it as Status Indicator in the Homey App
Sorry about that, but the Sensor (Status) is just useless but does take up unnecessary resources.
I did change the description to make it clear:
Test version:
2 Likes
@Arie_J_Godschalk , on slightly another topic, I just found out some of the Yeelights being offline, so I implemented this trigger / check to report on it :
ā¦yet nothing happened when those lights come back online (RED Exclamation mark disappeared).
I also tested , eg. cutting power - so they got the exclamation mark and again, nothing happened.
Is this working only for certain device types ?
I also sent diag. debug, just in case you see anything,.
Show me that image please?
Because there is a difference between a warning and unavailable.
No it should work for all, i log all devices into Simple Log to see if any went unavailable.
Okay, it might be because of the optional fields, i also can simulate not getting a log.
Hang on 
1 Like
Solved in testversion 2.13.7
Well done! After reselecting Create Flowcards, all is restored.
After all the testing, I am not sure what I had Numberfields before. I think I did not select Show As and left them empty, assuming default.
Now they are on Sensor (Default) and with Create Flows.
Thank you. 
