@thomas.c.howard this may come in handy for your apps!
1 Like
Just to clarify for everyone, yes, but it is LOCAL, so it won't work for cloud dashboards
3 Likes
A bunch of people experienced this during the beta. All I can say is I reloaded the page 4-5 tiems and then it worked and hasn't done this since. Since it's still a beta feature, I'm sure they're still working on it!
3 Likes
Would be a neat feature if we could specify a picture for local access and a different url for cloud access in the dashboard.
3 Likes
Just tried this on my Google Home. In Rule Machine choose Run Custom Action, select Actuator, select the Google Home Speaker, select play track, select string, then put the url in for the mp3 you wish to play http://[hubip]/local/[mp3uploaded.mp3]
9 Likes
No upload button or anything after I installed, same as reported above - but then I rebooted the hub again and then it became active for me.
I created a rule that created a file - that worked. Upload worked fine too.
[hub-ip]/local/fileName shows the file. file://[hub-ip]/local/fileName does nothing.
Oh that is freaking excellent!
Well done Hubitat Team!
1 Like
I have two HE hubs - in one the File Manager worked straight after installation of 2.2.1. The other I had to reboot the hub to work. Probably a glitch that the guys from Hubitat will quickly figure it out.
Nice. I can see this being a good way to store those online audio files keeping them local. Iām going to update my rules to point to local storage.
I feel there will be excellent use cases when it comes to writing programs under groovy. I just canāt think of a good example. 
Could something like Echo Speaks benefit from local storage?
Local storage, IMHO, is a HUGE enhancement to HE !!
It has a potential of opening the door for a lot of features using this local storage.
One that I can think right now would the possibility of an app doing the hub backup locally and, using an internal mail client or even a FTP client, send that backup file elsewhere.
Again, this is HUGE !!
Here is humble attempt to contribute ...
I think this approach will, sooner or latter, cause serious file management problems.
One problem that I can foresee is multiple RM Rules - and, in the future, apps, drivers and others "producers" and "consumers" of files - meddling with each other's files.
What I'd like to suggest, and I think that would be not too cumbersome to develop quickly, is, for start, to create files only in subfolders of /local/, and not directly under it. Doing so will make it a little more difficult for two different RM rules using the same file name meddling with each other's files.
So, to clarify what I'm suggesting:
- File Manager should have the option to create/rename/delete folders under /local/
- File Manager should only allow to upload files to folders, never to /local/ directly
- In RM, files could be read and write to folders, but never create folders itself - this should be a task of File Manager only
This approach would allow future File Manager enhancements like:
- Definition of folder and/or files disk space quota to avoid runaway RM rules eating up the available space
- Definition of file access rights
- Who (namespace perhaps ?) has read access
- Who has write access
- Who has Read/write access
- Who has no access at all (none)
- Default access right
- Definition of access scope definition:
- hub only
- hub + LAN access
- File retention option (great for a folder of temporary files automatic cleanup)
- Keep files indefinitely
- Keep files for a finite amount of time
- Define files expiration dates
What Hubitat and the community think about it?
2 Likes
Correct, the local mp3 played through my google home speaker.
I donāt see them giving us access to run services. Itās only a read and write location.
I'd make it simpler: people can create/use folders. I wouldn't restrict /local/ to folders only. I could see a reason for RM to create folders, but that functionality isn't necessary if it would be hard to add.
Yes, that would make it slightly easier to mess things up, but that's the user's responsibility to avoid issues, and your restrictions seem overly complexācould cause more confusion than its worth.
Doen't need to be a service - a Rule Machine already is a service, doesn't it? Can't a RM rule access a file and use a HTTP post to send it to an external entity? O run an app (another service, right?) that takes care of sending the file? The ingredients are already in HE. Local files are the "spices".
When everybody can do everything is the main reason the "sandboxing" concept was created. And one the benefits of Docker - isolation.
And isolation is something that's already present in HE - namespaces offers, as the proper name says, a different space where names (apps, drivers, methods, objects) are shared.
I think it would be too ...
The restrictions that I'm proposing are just these:
What would be developed latter, like the enhancements I've cited, are just possibilities - for now, just the forced isolation of files into folders (containers) would suffice and make room for future enhancements.
Imagine if, in the future, it's perceived that files isolations is necessary? What would happen with possibly a ton of files residing under /local/ ? It would cause a havoc or simply making impossible to better handle the situation.
If that situation of file isolation doesn't became necessary, files under folders haven't created any additional harm don't you agree?
As I said, beginning with the isolation of files under folders does not create any additional difficulty for the developers and I think that it would be not too hard to implement under File Manager in the near future (by Hubitat).
What I've proposed is not something that I've created from my head: it's the path that every file system has followed since the dawn of computers. It's present under HE: the /local/ path made available now for us is just that: a folder with restricted access.
What I'm suggesting is just to begin using local files with the possibility of grown in the future with the minimum impact on what the developers will creating using local files. That's all.
Whoa, don't create havoc for yourself! That is up to you, in your hands...
It's beta. It's a beginning.
3 Likes
@bravenel, I know it's a beginning. Sorry if you or someone else though that I've suggested differently.
I'm just giving my opinion and suggestion, and with the arguments why I'm suggesting it - and I think that this community is all about it: collaboration, sharing ideas. Am I wrong?
It saves using a Pi or suchlike for this kind of thing (images, mp3s etc). Schweet.
1 Like
