Absolutely.
Yep. That would be nice to have the Node-Red dashboard within FarmOS.
I don’t know if Farmier hosted NodeRed would provide some extra features. I find Node-Red quite easy to self-host. I’m more conserned about selfhosting FarmOS.
1 Like
Not so sure now, a dynamic menu name does not look as straight forward as I would have thought, but there are plenty of dynamic route examples. Although the functionality of the module is unaffected by the title so your module may well do the way it is, or perhaps with a more generic title such as “iframe” or “IOT” ?
“IOT” could work fine, but it may be used for completely other stuff too.
For example NodeRed dashboard to interact with FarmOS logs. No IOT in that use.
Is it possible to add several iframes this way? Or is it “one module, one iframe”?
I’m sure its possible to make the name editable, just I don’t know how and can’t currently find an example. Someone else may well come along and say oh it’s easy you just do …
I agree IOT wouldn’t be perfect for everything, but it’s hard to see a static title that sounds good though, simply “iframe” may make most sense but doesn’t really have any bearing on the intended content either.
Several iframes for one module should be possible, but how many does everyone need and what are they called? Would be nice for a module to be able to dynamically add iframes as well as menu names.
Of course. (At least that’s my experience 
)
iFrame is also very technical.
I was thinking of tabs on top. One iFrame for each tab.
Then there could be a menu named something like “External content”.
It would also keep the main menu cleaner.
1 Like
Maybe tabbed, but I wonder what effect that might have on the useable space for the iframe, the screen is already getting a bit cluttered on smaller screens especially with narrower aspect ratios.
External Content could work I suppose for a label.
I just added a second iframe to a module without much issue too, still using the same toolbar.
In the picture below I created 3 iframes here on 2 different modules.
Edit:
I wonder if enabling/disabling menu items might be easier, maybe offer a selection of names that could be used, allowing multiple to be enabled at once if desired?
2nd Edit: might just be what I was looking for in the first place.
Great. It was really easy then 
The more I think about it, a NodeRed dashbard interacting with FarmOS will be quite useful in several cases. Not only for IOT.
1 Like
It’s all easy if you know how…
Absolutely, everything from handling CSV files, connecting with other API’s to an alternative to quick forms.
After spending some time re-branding the Grafana Module to a Node-Red module it looks increasingly like a generic iframes module would be more appropriate.
I’ve made it so multiple iframes can be added with and option to re-label and enable/disable. At the moment its just 2 but 3 or 4 wouldn’t be any more difficult.
There is still only one iframe field per asset, not sure if there is much point increasing that.
1 Like
Great work!
Not sure what you mean by one iframe field pr asset tho.
But it seems pretty perfect as far as I can see.
1 Like
@SirSundays Grafana module adds an iframe to the menu bar but also the option to embed individual iframes for each asset, so a graph relevant to that particular asset.
So, if for instance I wanted to associate a temperature graph from my upstairs to cow 345 
I can. (There is probably better uses for that too! )
I think it’s a pretty cool feature, with lots of potential.
Ok. I get it. Cool feature indeed.
I really have to make some time and get my Pi up and running with Node-Red now… 
I’m running it on an ubuntu laptop at the moment from a snap install. Works fine, but I had trouble installing custom nodes. Seems like it’s not the recomended way of installing.
If we get this module available for hosted FarmOS too, it would really rock.
That would provide a manageble and powerful environment.
And hopefully a lot of useful ideas will evolve
1 Like
Repo for rebranded Generic iframe module.
1 Like
Nice.
@mstenta I would love to try out this on my hosted instance.
@Farmer-Ed quick review of the farm_iframe module:
This only describes iframe_1_url, but there is also an iframe_2_url.
I wonder if it would make more sense to use a sequence type (aka indexed array) rather than hard-coding each. Then it could be scalable to more than 2 (even if your config form only starts with support for 2).
Also, if your config form saves the config, then you don’t need to create anything in your config/install directory. Leave it up to the user to create that through the form, rather than installing with 2 defaults (which both currently pull in https://eolab.de/). Then it would be starting blank.
Do you need all these templates? It seems that one generic one would suffice.
Ideally there would just be one route with a parameter. See https://www.drupal.org/docs/8/api/routing-system/parameters-in-routes/using-parameters-in-routes
This is unnecessary. farmOS already grants the access toolbar permission to managed roles: farmOS/farm_ui_menu.managed_role_permissions.yml at 04bf771d91cde8276b67090d2b97c4e4558332b9 · farmOS/farmOS · GitHub
Menu items can be defined dynamically in a “deriver” class, which would make this more flexible. We do that in a few places in farmOS that you can use for reference (search for extends MenuLinkDefault in the farmOS code). See Dynamic menu links in Drupal 8 with plugin derivatives | Web Omelette
I don’t think this needs it’s own FieldType, or FieldWidget. It’s just a textfield. The FieldFormatter could target the existing text field type. I guess… maybe there’s some value in keeping them separate.
I see there is some prior work on this in Drupal contrib already as well:
Haven’t tested those, but maybe duplicating efforts?
The module will need a composer.json in order to pull it into Farmier too.
Sorry for the deluge - hope that helps!
1 Like
Thats OK, @mstenta and thanks for taking the time, I was just sharing the repo that I’m working from and aware that “some” tidying may be in order 
. But I will absolutely take all of the above on board.
2 Likes
@pat, I’m still working on this, but going to try and redesign it a bit, using the provided advice above and a bit more researching to make the options more dynamic.
@mstenta are you happy for modules with iframes to be included in hosted Farmier instances? Any security concerns etc. before I spend too much time/effort on this?
1 Like
@Farmer-Ed There are some security considerations allowing iframes, yes. But I wouldn’t be opposed to enabling this module for a few folks who I trust, who are experimenting with advanced stuff like this.
I’d like to read up a bit more on iframe security considerations before making it available more widely. This SO post has a good overview (for future reference): html - Why are iframes considered dangerous and a security risk? - Stack Overflow
In the case of farmOS, and embedding iframe into the farmOS UI, I think the primary risk is exposing other users to malicious URLs embedded in iframes. That can be mitigated by only allowing high-level users access to add URLs to iframes, but something to think about more deeply… especially if we ever foresee farmOS pages being made visible to the public.
2 Likes