Very nice @Menno_van_Hout !
You can run this in the floweditor. Does it give a response when you hover over the bottom of the card after executing?
Thank you for the prompt response, Arie.
Yes, it says it finished with a series of characters representative of the log headers (blob data, I presume). Yet no matter what action cards I attach to that one, they all fail with the same 413 error posted above.
Which homey do you have?
And if you select the text from the bottom part of the flowcard, put it in a textfile and save it, how big is the file?
I’m using the Homey Pro (early 2023). I couldn’t figure out how to grab the text from the card as it would disappear when I tried to select it. Not sure if this is comparable to the payload in the flow… but using http:///api/app/nl.nielsdeklerk.log/ I was able to get the log data and save it as a txt file which was less than 350kb.
Okay, then I guess it’s not an homey(flow) issue (it can handle files up to about 10mb).
What kind of ftp server are you using?
Perhaps the server has an max file size configured?
What kind of FTP server?
Is it configured active or passive?
Is there a firewall between ftp site and homey?
Is there a passive external IP address configured on the FTP server and are homey and ftp server in same internal network without NAT?
There can be made a lot of mistakes with “simple” ftp configuration.
If FTP is configured passive and the external IP is configured as well, to be able to ftp into the server from outside networks, then Homey need to use FTP Active and not Passive ftp.
In case of firewall in between, make sure the FTP Data path is configured in the firewall as well and/or the correct Passive FTP ports.
It’s the same FTP server I’m using to pass images to in an unrelated flow. To confirm the custom FTP Client is set up correctly, I dropped that into my image snapshot flow (secondary to the native “Blink” save a snapshot to an FTP server) and it completed successfully without problem - taking the image from the preceding Blink action and saving it to the correct FTP folder. I don’t believe these errors have anything to do with the FTP configuration.
To further expand on previous observations, it doesn’t appear to matter what is downstream of the Get the (whole) log card, everything fails with the same error. The duplicate “Get files from” Custom FTP action works correctly when directly downstream of the “Every 3 Days” trigger - bypassing the Get the Whole Log action. The same action fails when downstream of the Get the whole log action, whether incorporating the log data or not. To further support this, even a simple write “Testing Flow Card” to the text variable “var_TestText” fails, this action again has nothing to do with the ftp server or size of the log, yet fails with error 413 regardless.
Does it work if you export the log as an Excel file, instead of a csv file?
That’s really weird.
Flows can handle pretty large files/tokens, I believe, up to about 10mb, although I’m not completely sure.
Perhaps @Emile has an idea of the max size an argument could be in flows?
Although, I think there is something else wrong with how the flow is handled, since the Get Logs card also gives an error after retrieving the syslog.
Alas, it does not.
Okay I didn’t realize when using the api to get the logs that they were truncated until diving into it after work. Exporting through the app interface returned 10k rows with a file size of 3.3mb.
Prior to this discovery, I was able to use a script leveraging the api and pass the results to the ftp action which successfully saved the csv file, but it was only around 800 rows, unfortunately. Is it possible to not truncate the results via the API? I could bypass any Homey Flow limitations, if so.
Your help has been much appreciated. Do you have any other ideas which I might pursue while awaiting an acknowledgement/response from Emily?
Well, what happend if you try to Export the log as excel in the flow?
And what happend if you retrieve the log in HomeyScript and use it from there as a token?
Or if you generate another large token through HpmeyScript or a variable or something?
I have a autoexec flow that starts whenever my Homey Pro is (re)started :
Yesterday app. at 11:40 I sgutdown Homey for a USB backup, the restarted… Everything worked fine, the Autoexec flow ran until the end. …. but today I noticed Simple (sys) log did not create any entries after that :
But tonight at 1:00 it suddenly started ?
It looks like Simple (sys) log did not start ? But there is no way to know since I don’t have a log…
And why didn’t I get an errorhandling restart of the flow ?
Could it be that the Simple (Sys) Log app had not yet started when the flow was executed?
Instead of the ‘Homey Pro is started’ card you could also use the ‘Homey system is running - All activated apps are ready’ card:
Thats why I test with the error on the first card with Simple (sys) log.
I’d expect the flow wouldn’t continue when Simple (sys) log wasn’t running. But it seems it does.
Maybe I should install Sysinternals and use that card..
So this should work ?
Yes it should. I had a similar issue with the Simple (Sys) Log app and some other apps. Also you never know in which order Homey starts apps. So I ended up using the sysInternals card, which works (at least in my case) and triggers only when all apps have started.
1 Like
Hi Arie,
first of all, thanks a lot for Simple (Sys) Log – I’m using it heavily to log events from my Homey (Early 2019) to an external web server.
My setup in short:
Flow: “Get the (whole) Log as CSV”
HTTP POST card → sends the CSV body to my web server
On the server I process the CSV and write my own text/CSV files for later analysis.
Until 31 October everything worked fine. At that time I noticed two things:
The CSV now contains 18,000+ rows instead of ~2,000 before.
It looks like the CSV format may also have changed slightly.
Because of this, my old server script broke and the HTTP POST now sends a huge amount of data every 5 minutes, which is a bit overkill for my use case. I’ve rewritten my PHP to handle it again, but it would be much nicer if the amount of data could be limited on the Homey side.
Would it be possible to add something like:
a setting for “Maximum number of rows in CSV export” (e.g. 100 / 500 / 1000 / 2000 / all),and/or
This would be very helpful for users who push the CSV via HTTP to an external system, or who don’t need the full 18k+ entries every time.
Thanks again for your work on this app!
Best regards, Guido
