Apart from some specialized widgets, the sitemaps are missing an “include” mechanism. From an outside view, this doesn’t look too complicated.
Include file="<filename>.sitemapinclude"
And just replace the include stuff with the file contents. Sure, some syntaxparser would be neccessary, but this almost the same as for sitemaps, just don’t enforce the Sitemap object.
According to my opinion a large number of the requests for user management could be handled with this. (I assume, many people just want to provide a simplified view to some users. May be wrong, may be right. )
I was hoping that it would be like on apps on android, so that my GF easily can see when she launches openhab app/ sitemap in the browser that she then gets a notification that updates are available and get asked if she want to install them or not. If she then clicks yes then it starts the package manger on the OH server.
Well it needs to be programmed in the various GUI for OH (android app, sitemap in browser) so that when it starts it check the local server version vs Openhab server version for bindings updates and system updates.
I am not talking about finding out if the app has come in a new version or not, but my GF never goes into to putty and type in sudo apt-update to find out if something should be updated or not…
Just go to the tutorials section, there is some example to exactly do that.
In order to perform the upgrade you may need to elevate the user permissions.
But i wouldn’t suggest something like that, i never saw a maintenance upgrade for openHAB, usually it’s a feature upgrade which needs manual interference most of the time.
openHAB is just the Framework, the real App is your Sitemap/HABpanel.
What my GF would like, and I also kinda is to get a push notification when 01,02,10 in the image above should be done, then just press OK, confirm with the openhabuser and password and a command is sent to OH server which then execute the above commands. Will this be hard to implement @ThomDietrich ?
Without having to find a pc, log into putty and then do it… OH is moving towards a non geeky Home system, where you can go online buy a HUB(rpi, with openhabian installed on it), plug in power, download openhab app on ur phone, then setup basic info as sitemap name, wifi credentials, usernames etc… then it autodiscover your things through Paper UI, and you create your rules like strigify and your gui with habpanel inside the app on your phone…
However it does not check if a binding is in a new version or?
With openHAB you always get a full release. I have no idea about marketplace bindings.
But as i wrote before, you usually get no benefit from upgrading openHAB. The benefit comes when you use the new features somewhere in your sitemap or rules.
Look at the open Issues and comments on Issues. This particular discussion was on an Issue on Designer.
The current Rules Engine does not support:
reusable libraries that can be distributed through the IoT Marketplace
the ability to use other more popular programming languages (e.g. JavaScript) for the logic versus a custom DSL
there were other things kai mentioned that I can’t remember at the moment.
The current Rules DSL will not support this.
Are you running 2.2? Since 2.2 you get line and column numbers in openhab.log for syntax errors. Sadly, it does not support (nor can it support if I understand correctly) line numbers for runtime errors. Yet another good reason why the Experimental Rules Engine is needed.
I don’t know your GF, but i shudder at the thought of my wife blindly applying updates to OH. If one is running the SNAPSHOTS they necessarily need to be prepared for stuff to break since the snapshots are Alpha level maturity. If running the release version, then there is a high likelihood that there might be breaking changes when going from one release to another release. So again, one needs to be prepared for stuff to break.
Given the high likelihood of something breaking I strongly believe that any upgrade needs to be done in a controlled manner with fallback options. Personally, I don’t think it is wise to allow any user of OH to blindly upgrade it.
With the start of 2.2, there is now the infrastructure in place for maintenance releases. There is no guarantee there will be one, but it is not theoretically possible.
10 shouldn’t really need to be done more than once unless openHABian makes some major changes/additions.
01 pulls down updates of openHABian itself and 02 is an apt-get update; apt-get upgrade.
If you are OK with blind updates/upgrades, which having a button to press on the sitemap would necessarily be given the lack of feedback, why not just set a cron job and have it run in the background once a week or once a day or something?
Drop the following into /etc/cron.daily and it will implement 02 once a day:
Again I can’t say I would recommend this because there may be changes to config files that the package may make (remember the switch to log4j2 in OH? other packages will do the same) and I think -y will just blindly reject those changes and keep the old version.
In short, until we have OH running on something approaching firmware instead of a general purpose OS and there is a mechanism to upgrade the whole thing in one go (i.e. replace the whole firmware, not just upgrade each individual package one at a time) I cannot recommend performing any upgrades without finding a pc, and logging in to putty to do it.
All that being said, there are web based admin apps that will let you do 02 and will provide a web based command prompt to do 01 and 10.
That was not my point. Just updating openHAB will usually bring no benefit, you need to use the new features. Things need to be recreated, triggeringItem need to put in rules, same goes for MemberOf.
So, unless, the person doing the upgrade to the framework is also capable of applying the changes to the custom application of rules, sitemaps etc. you won’t get a benefit of the framework update.
That’s exactly some of the information i am looking for.
If i remember correctly, at least the UI of the rules engine was something like that (dropdown for each bulletpoint):
select item to trigger
select trigger type
select action
select item for action
This would be too simplified for my taste. Maybe for everybody who is able to write a script. If it is possible to write similar complex rules like the current one i am all for it. But if the direction is “one item, one trigger, one action”, I’d rather stay with the current one.
There is a + for each bullet point that lets you create multiple Items, multiple triggers, scripts, conditions, etc. for each. You are not limited to just one for each.
There is also the addition of a when clause that lets you set conditions under which the Rule executes (i.e. the much requested and in the Rule trigger). That is the “but only if…” section. I’ve added two to each field in the screenshot above. You can also see that you can have multiple actions for a given Rule as well.
It does appear that JavaScript is the only language currently supported but I remember talk of all of the JSR223 languages being an option at some point (i.e. Jython and Groovy as well).
The Experimental Rules Engine has not yet reached parity with the Rules DSL in capabilities (it is called experimental for a reason) but I can already see that it will be a great improvement of the Rules DSL in the not too distant future.
This excerpt from eclipse smarthome makes me shudder:
Concept
In general this rule engine aims to support rules defined with syntax similar to:
ON item_id state changed IF item_id.state == desired_value THEN item_id2.state = desired_value2
Not many of my rules are like that, just the simple ones. This type of logic is quite often directly inside my devices (e.g. heating, window contacts & temperatures).
I mostly need openHAB rules for special cases, when standard functionality is not sufficient. This would be most likely somewhere inside “a given script”. If the “given script” will be restricted to the above standard case (or a limited number of additional others), i will be not that impressed.
I usually need some string concatenation or splitting, calculation, conditional logic based on that as well. I could replace that with a mass of proxy items and transformations, but i am already well above 1500 items, i would not enjoy that.
I don’t care which language that will be, I am at least a bit familiar with all common languages, even the current language would be fine (the most unusual i’ve seen in a long time).
If you are editing your jsondb, what tools do you use? VS Code or some scripting language?
There are no such restrictions in the scripts. That concept section is describing the overall structure of a rule, not the sum total of what can be achieved with rules. A rule will have one or more triggers, zero or more conditions, and one or more actions that take place when the trigger occurs and the conditions evaluate to true. One cool thing that may not be apparent is you can write a whole JavaScript script as a condition which can give you the ability to have very complex conditions.
The Experimental Rules Engine as it exists today has no such restrictions. The only reason I’ve not experimented with it much yet is I don’t think it yet supports Timers, though I mostly use Expire timers these days so maybe it is time to start playing with it.
The script will support anything that can be done in JavaScript. I don’t know if it will be possible to import JavaScript libraries so you might be limited to just the core of JavaScript, but there is nothing you mention that cannot be easily done using just core JavaScript.
I rarely directly edit my JSONDB. On occasion, I’ll open it and fix something quickly using vim. Mostly, if I need to do much more than that I’ll go through the REST API. But the vast majority of the time I let Automatic Discovery do its thing and I just accept the discovered Things from the Inbox either through PaperUI or the Karaf Console.
I reviewed the experimental rule engine, just to know what i am talking about. Overall, having such a feature, is an improvement. No need to think of syntax, except for the code body. And that being javascript is also more common than what we have now.
The whole structure is (technically) the same as what we have now, not a change of approach like a graphical editor. People who are afraid of text editors may enjoy using it.
So far, so good. People who are used to editors like VS code will seriously hate it. A simple Web-Text-Input widget is not state of the art. The item dropdowns are horrible, if many items are involved. This is a problem throughout the whole PaperUI, so i do not know if this will ever be changed.
Since the apporach is the same as now, it’s easily possible to add an import function to load/reload the files into Jsondb. But if the direction of openHAB is that file usage is a bad approach, i doubt it will be done.
May i ask how many things and items you are using approximately?
I am running about 130 devices and between 1500 and 1800 items. All the large changes in the pipe are aimed to support smaller installations or support less technical users, while may making maintaining of larger installations more difficult. I understand, this is the majority of installations, but the openHAB core is able to support both easily, it’s just a matter of different input methods.
Sorry for bothering you with questions, but i am currently thinking about either staying with openHAB and becoming a member or switching to something else (long term). The current state is fine, the outlook may be even finer, but some details in the implementation trends make me fear if i will be happy in 2 years as well.
I think overall you are looking at things are they are now and projecting into the future that things will just as they are now.
OH is constantly growing and changing and migrating. It is unreasonable to expect that the Experimental Rules Engine will continue to use “A simple Web-Text-Input widget” in the long term. You are looking at a work in progress and saying “well, this doesn’t help me now” and projecting that into the future.
I’ll say it again.
text based config files will not go away until the JSONDB stuff and UIs have parity, even for large installations
the Rules DSL will not go away until the Experimental Rules Engine has parity, to include something the equivalent to VSCode
even when parity is reached, it will probably be a year or more before the text-based stuff gets deprecated
in truth, the text based stuff will probably never get deprecated, though over time new features will only be added to the JSONDB stuff
I do not see any move towards deprecation of the existing text config files for at least five years, maybe longer, given the current rate of development
Many of the maintainers run very large systems as well. I doubt they will make any changes that make maintaining their systems harder.
If you are basing your decision to stay with OH or not based solely on the state of the experimental and in progress parts of OH as they stand now, you do yourself a disservice and it reflects a lack of trust in the maintainers. No one is going to remove anything from OH until there is something in place that works just as well for both “regular” users with modest technical skills and smallish systems and “power” users with massive deployments.
Software does not spring fully formed from Zues’s head like Athena. It takes time to develop. So developers can either wait until their software is fully built and capable (and never release anything), or release changes and features as the become capable enough.
I will not be surprised that all developers continue using config files and Visual Code extension rather than Paper UI for their own HA system. Of course I hope this feature will never disappear, I think it is the best option for advanced users.
1.) Editable datetime on the sitemap.
2.) Built-in delayed rules startup. If my rules start before my bindings, I sometimes get a lot of errors.
Right now I am delaying my rules startup with a combination of Thread::sleep and “when System Started.” For each rule, I have an if statement that checks if the system is done starting.
