While helping on another thread I went looking for the demo config files. I thought I found them at https://github.com/openhab/openhab-distro/tree/main/distributions/openhab-demo but there are no JSON files there meaning at a minimum the MainUI stuff is missing. But the demo shows other stuff like Items are managed so I don’t think those files are relevant at all.
So I’ve two questions:
Is the demo config on gitHub somewhere and I just can’t find it? Or is it maintained independently?
Are the demo files I found still relevant? If not shouldn’t they be removed?
You mean the JSONDB? Because the main UI pages and HABPanel config are there, so I’m not sure how that works (which reminds me I still have to update the HABPanel docs…). The rules I added including the Blockly one and I think even the items are now managed in the JSONDB.
I never did the markers on the first floor of the demo floorplan page, and maybe there would be some changes required for the demo scripts as well.
The way I do is is I capture both my conf folder (which has almost nothing in it any longer) as well as relevant folders from userdata in my git repo (the rest added to the .gitignore). For the demo I suspect that all that would need to be captured are the JSONDB files and perhaps what ever file the demo user is defined in.
Before I ran OH in Docker what I would do is clone this repo and then softlink the conf folder to /etc/openhab and the userdata to /var/lib/openhab but now with docker I just mount the two folders to the right place as volumes.
Editing and updating is a little awkward for sure but it seems better to suffer a little awkwardness than to not have the demo source controlled at all. To do it properly you’d have to spin up an OH instance with the configs supplied, edit through MainUI or the REST API, save and then commit. But openhab-core was updated so it preserves the order of entries now so the diffs between versions will make sense and not get cluttered with a ton of “fake” changes because the file got saved in a different order.
Thanks Rich, this is a very valuable insight as ever. The demo server doesn’t use Docker rather the DEB/APT packages but I would suggest something like this going forward:
create an official demo repository (openhab-demo) containing all necessary configuration, so everyone can contribute to the demo, without figuring out it actually being buried In the distributions files to work
do some script magic to apply this version-controlled configuration (the official one described above or anyone else’s, really) to a (cold, ie. not running) instance, checking versions and compatibility etc.
do that regularly on the demo server (demo.openhab.org) - note that this server is not managed by the openHAB project itself, rather by the openHAB Foundation non-profit which still accepts memberships and donations.
Also in “Scripts” it says “Code in 4 languages”. We should add Blockly and Ruby in there too. When that is clicked, only Rules DSL button seems to work. The others don’t seem to be doing anything.
When clicking into Map, Charts or Temperatures button, there’s no “obvious” way to get out of that to get back to the main screen.
Thank you for going through the demo to find some of the stuff that doesn’t work. We should have a fully functional demo config.
Your listing of the “Code in 4 languages” made me realize that we need to be careful that we don’t open up ways for someone to attack our demo server through the demo app. I wonder if it’s possible to disable executeCommandLine.
The ability to create/save rules/scripts and Things/Channels need to be disabled - with a message popup saying “Disabled for security reasons”. We probably still want to let people go into blockly and play with it, just not save it. Even blockly allows entering arbitrary js code. I don’t know about JS, but in Ruby there are many ways to execute a shell command.
I don’t think JS has that much access to the command line. GraalVM gives a node like environment but not a full node.js and many things like that and making http calls are not supported.
Ruby has ultimate power to do everything: download and install any gem from any source, and execute code. This means it can do anything, from HTTP access, to running DOS attacks against external targets, if the internet is open. So definitely do not let people save their script.
Even JS can be used to do silly things like a forever loop or infinite recursion.
