Hi Arie, since I don’t use this app myself, my motivation is not that great. 
But if no one is willing, I can of course do the translation.
Could you please add a file README.de.txt.
1 Like
Done!
And thanks!
1 Like
The new version of BLL is now live:
- BLL has been fully put into translation, flowcards are redesigned/re-titled and translated.
English
Dutch - Also a small redesign of the Settingscreen to better fit multiple devices.
- The File Server is now configurable from the Settings.
- Formats Z and ZZ have been added: GMT+1 and GMT+01.
- Settingscreen updates smart, using fever resources as before.
- No more startup issues
- Memory performances has been improved when having “Client” apps like GS, FTP client or Simple Log:
A BLL restart/re-install doesn’t icrease memory usage (of BLL or the other app(s)). - BLL package has been stablisted.
- New custom module to convert JSON into Excel and Csv has been implemented and is in use in the Simple Log (test) App.
3 Likes
This error message occurs since the last update of the app. Am I doing something wrong?
1 Like
I guess not, i also get this error. My bad, fixing it right now.
1 Like
BLL just got a new Flowcards: Format JSON as CSV or Excel
This will allow any JSON input array (or object-array) to be converted into a CSV (or CSV-base64).
Also, Excel:
Its in test now.
1 Like
Excel files can now be generated with a Schema (in test):
Check the App Settings for an example (and other Excel settings):
But whats is your used case for this function?
I understand the export/import function for variables, but because in (manual) export there is the need for a whole process behind it to do something with the information, is it not better then to export directly to InfluxDB or Loki or… to build up historic data of Better Logic numerics (Insights seems to fail me often (no data in cloud)).
Don’t misunderstand me, you do very good work, but I am bit critical about this function and the usability and the fact that apps get so full functions and possibilities that it is getting too complex to learn and use, starting to feel as multiple apps in one app with more and more overlap with existing apps and basis functions (functions / homeyscript …) , with effect on memory usage (which you already try to keep as low as possible).
(sometimes it is hard to stop when having fun)
1 Like
Well actualt, people asked for a way to put the variable in a DB. Insights do not export variables.
Thats why i created the Export functions.
Ofc the idea is to have flowcards to export the files, so you can automaticly do that every day.
However, i didnt have time yesterday to finish the flowcards, only the buttons in the app settings.
Also, it"s a good way to test the json-Excel function, for which i personally see much usage.
But the export-in-app-settings, thats just to for easy testing mostly.
The upcoming flowcard to export the variables is what it’s most about.
The idea is to create the same flowcards i just created for Simple Log:
Export the variables (or Log in SL’s case) through flowcards (automated) as JSON, CSV or Excel (give people the type the need), as text or Base64 file, so the can uatomaticly save it every day.
In FTP Client i have already build in a new flowcard to save Base64 files, thus: You can save the Log/Variables every day on a FTP (on Homey itself for instance).
Indeed, that’s why i am building it like this:
BLL can do a lott already, and has many libraries in it used by FTP, Google Services, Simple Log and BLL ofc.
But BLL is still just 4.5MB install size(!), when i took over, BLL was a little over 3MB install size.
(while it didn’t have all the libraries in it).
And while the memory usage has increased, BLL is still lower in memory usage then HomeyScript alone!
So, i am very happy about this 
Indeed, but i don’t wanna rebuild the wheel al the time.
There are already apps to write data to DB’s.
So, i prefer to give a way to export the files (in flowcards) and hope that other apps like Email-Sender or InfluxDB will be able to use base64 files as input.
Here you go, here is the Use case:
With this, i consider the ticket for this “resolved”:
QlusterIT / nl.qluster-it.BetterLogic / issues / #12 - Be able to save numeric values to InfluxDB — Bitbucket
Work together with the InfluxDB app developer
1 Like
Well, i love working together with other app dev’s, but i think we already have what is needed:
There is a new trigger flowcard: Any variable changed (not the old debug version, but the new one with tokens).
It contains the Variable Name, Type and the value as type:
With this single card, you should be able to log every variable change to the InfluxDB.
In the App Store it shows verious cards to write single record:
You can combine these to get this (im using log cards):
First: Any variable changed, then check what type it is (string, trigger, number or boolean), then write the specific value to the log/DB.
2 Likes
do you want to update influxDB each time a variable is changed?
Yes, every time a numeric variable is changed we need to send an update to InfluxDB and doing that with flows Homey will disable the flow frequently, because the flow runs to often, so it a numeric only changes every 10 minutes then it can be done with flows, but if a value changes every few seconds or every minut, the flows will get disabled, over and over again.
1 Like
Why?
As long as the flow is not running, i believe, 60 times at once, it should work just fine.
Please test it, if indeed the flow get’s disabled, i’ll try to work on another, more integrated solution, deal?
EDIT:
Okay @M_a_r_c_o , after running my performance test for BLL, meaning, updating a few variables many many times a second, the flow got disabled (150 updates/executions in less than 3 seconds).
So, this indeed is not the best solution.
I’ll try to think of something else.
1 Like
Just FYI @M_a_r_c_o , why this is somewhat more difficult to develop.
For other apps to connected and recieve updates that a variable has changed, the would need to connect to the AppApi and listen to realtime messages.
And there is a memory buildup in these realtime messages.
Thus, using the realtime like i do now for BLL for updating a few settings, is already building up memory.
Fortuantly, this buildup is very minimal.
However, shooting realtime messages more than a flow could handle, i think this could really crash and burn the api, as in, create a hugh memory leak/buildup.
So i’ll first do some test what’s the best way to get that many updates to a “client-app”.
