2018-10-23 15:51:04.416 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: ReferenceError: "executeCommandLine" is not defined in <eval> at line number 1
I’ve tried several formats and ways to define the script, mostly blind since I don’t know what is appropriate here but I always get something indicating that my JavaScript is completely malformed or it doesn’t know what executeCommandLine is. But based on the JSR223 Actions.js examples that line should work.
I know there is some overlap between the ERE and JSR223 but they clearly are not the same and features that are available in JSR223 are not in native ERE. And since the vast majority of ERE users will be writing the scripts like the above that is what I’m looking for status on.
Jython and Groovy are not options under “the scripting language used”.
tl;dr, just because it works in JSR223 doesn’t mean it works in ERE, yet.
I don’t remember disagreeing with this ;). I don’t mind people opening up multiple reports unless they are clearly linked and we’re trying to solve a specific issue. One thing I do dislike is people assuming that two issues are the same when often they aren’t…
I have one: The ability to tell if a device was changed from outside of openHAB (for example a user manually turned on a light) or from within such as a rule. Even something as simple as the triggering source property being either something like “system” or “binding” would be useful I think.
Id like to see the Private cloud of Openhab Cloud being intergrated, ie a component fully installed as part of the install. You either select internal or external. Not that the external cloud is unreliable but I prefer all on premise
Echo the remote access restrictions, there needs to be more granular control over security for other users as Vincent as mentioned. Allowing certain users to see/do certain things would be great
Graphical interface of the debug system with the ability to easy filter based on binding etc
That’s a great question thanks for asking! So here are just a few ideas for issues i have had:
Built in user authentication (Instead of using nginx proxy)
Built in SSL generation using Lets encrypt (Instead of manual generation) or manual addition using Paper UI (this would also solve the need for nginx)
Built in configurable proxy (give the ability to access things like camera images and video streams without opening individual ports for each camera on the router)
Built in Terminal client in Paper UI for CLI access instead of using third party tools
Built in DynDNS or other DDNS reporting (auto update dynamic dns)
Built in UPNP client to open router ports (auto open router port for access)
Separate log/register for device state changes (Instead of scrolling through miles of log files)
Tagging support in paper UI (instead of having to manually add them through the console, useful for Alexa integration )
Ability to trigger zwave inclusion and exclusion from sitemap items
Ability to have code generated sitemap items or dynamic drop down lists (Listing radio stations, songs, etc)
Ability to have multi-line sitemap items
Built-in GPS tracking and reporting in the mobile app (This might be a bit out of the core scope)
Built-in Text input fields in the mobile and basic UI (This might be a bit out of the core scope)
I know there was a couple more things that would be nice to see but I cannot remember them right now, so I hope this list helps.
It is not. Depending on the item, you may want to reset it to default or keep the persisted value, so you need a rule in any case. You can deploy a single rule to trigger on ‘System started’ to set all default values in one go, and unlike with a simple item property, you can even apply conditions here.
I’d even go further and say that the ability to set it via config will result in a number of issues where people set defaults and forget about when programming their rules. From someone’s point of view to spend a lot of time on supporting other people debug their rules I’d therefore even vote against having this.
Yes the need to check for NULL is annoying but that’s integral part of proper programming anyway, and the main root problem is the unreliable startup order so rules sometimes get processed while items aren’t available yet. But that issue already is on the list.
Either way, this thread is meant to consolidate needs that several people have in the core framework so developers know what they should focus upon, and my point was that none of your points require any changes to the core but can be solved differently without too much hassle really.
On Smart Home Day, @henning reported plans to replace the current scheduler.
I agree it would be great to also allow for user-provided scheduled actions/rules to be managed by the framework, maybe there’s a chance to combine this ?
@kai stated that essentially ESH automation engine is to replace the ‘old’ engine in the foreseeable future (here’s the recording).
But I think there’s still many details that need to be sorted out.
As an end user of Openhab, the one thing I would really like to see improved is the App functionality and the ability to do most things that PaperUI and Habmin can do but with greater ease through your phone or tablets Apps.
Currently, to add or exclude zwave devices, enable/disable bindings, and so forth requires a web browser to do those various things. I would really like to see back-end administration functionality added to the Apps. The ability o restart your System via the APPwithout needing rules, and so forth.
Just think about multi-user supports. If/when that gets added. Would I need to add users and permissions via logging in via a web browser?
One other item is the ability to both Upgrade and possibly downgrade your OH2 Version via a GUI and/or thru an app. Currently this can sort of be done with some rules and dummy switches, but a built it upgrade option would be highly desirable.
Sorry to be a bit unfriendly here but I think you quite misunderstood the way OH is composed and built.
PaperUI/habmin and BasicUI/HABpanel/ClassicUI are intentionally separated as they serve different purposes. PaperUI/habmin is for administrative tasks only such as to add devices.
These are more or less one-time (or few-times) tasks. This functionality isn’t needed by and not meant to be accessible to end users, so there won’t be any apps to duplicate this. Stick with using the browser.
On upgrades, there’s another (intentional) separation/layering. The OH core is built to run on top of Java but it doesn’t include all the functionality OS, Java and external helper apps such as mosquitto provide.
The upgrade process in turn is highly OS specific and as such out of scope for the OH core framework.
If that’s what you’re looking for, have a look at openHABian or any of the commercial appliance type solutions built on top of Eclipse Smart Home.
Not unfriendly at all And perhaps I misled by saying ‘enduser’, and by that I meant someone like myself who is not a developer, but runs their own OH2 system at home and is familiar with the setup, installing from scratch on a linux or other OS machine, setting up mosquitto, etc.
And by enduser, I was more implying the ‘administrator’ of the system. The person who may be adding devices, enabling new bindings, etc, giving mult-users rights and permissions, etc… I think Zwave may be a good example. You add a new sensor, switch or something. But then need to go a web browser to add this device into your zwave network. Yes, all controllers and hardware different, and I understand that as well.
Having an ‘admin’ account with PaperUI and other access from your Phone or Tablet and not needing a web browser I think would make OH2 more user friendly to the the novice in setting things up. This sort of goes along with the multi user and permissions request. Just adding on to request that the Admin or Super Admin of OH2 should be able to do things without needing to go a web browser. Many of today’s younger generation do everything off their phones and tablets with various apps, and very little actual web browser stuff.
Perhaps this not a core framework item, but is something I think many would like to see.
On a final note, I could one day foresee the Road to Happiness following a similar path of XBMC/Kodi. What started out very small now has various 3rd party vendors selling prebuilt Kodi boxes. Similarly one day to see 3rd parties selling prebuilt OH2 boxes with the main zwave, zigbee, Bluetooth, wifi sensors and a preconfigured OH install.
Not really, it would just be another frontend to the same API, without any added benefit.
You (the user) would still need to understand the meaning of all the settings - and there are so many more than are in Kodi.
What you probably mean is to turn all of OH into an appliance, so it’s rather the following you want:
I don’t, this is illusive. OH is so much more complex and flexible than Kodi is, effectively exponentiating the efforts of turning openHABian or even openHAB itself into an appliance.
For reference as there’s apparently a larger number of people to totally underestimate the efforts involved:
this has been discussed e.g. here.
I must have misunderstood or more likely miss remembered. I wish I could find the thread, it was actually a pretty good one.
I’ll start being a nuisance then.
It’s kind of minor, but I’ve dealt with several users who, for example, keep trying to toggle the Switches from the Network binding and are confused when nothing happens.
Either I’m misunderstanding or there already is. events.log only has Item and Thing state changes.
I think this would need to be implemented on the Zwave binding and exposed as a Channel.
I believe there is already an issue open for this on the Android app repo. It has been much requested but you are correct, it isn’t really part of the core framework.
It’s the details that I’m looking for. When ever I try to do anything more than logging from an PaperUI defined Rules I get ClassNotFoundExceptions. I’m mainly looking to know when there is enough there that it becomes a viable replacement for Rules DSL so we can start the documentation efforts.
Thank’s for the video link! Are there any others from the recent meet up in Germany? I must have missed the announcement if they were previously announced.
Perhaps it is worth pursuing making PaperUI a bit more mobile friendly and or making a PaperUI App. Personally I already find PaperUI to be quite mobile friendly but perhaps I’m missing some pain point. @ptmuldoon, what is it about the web browser interface that causes problems for you? On Android at least, you can even “Add to Home Screen” your PaperUI and it will have it’s own icon and pop-up like an app when you tap it.
I completely agree though, managing user permissions, and all the other tasks mentioned are administration tasks and do not belong in the openHAB Phone apps themselves.
@travellingkiwi
Changing entries in the database is a problem!
This database by design can have several “archives”, with each archive covering a different timespam starting with the actual time. Entries in archives covering longer timeframes are calculated by several minute-wise entries.
A later change of such an entry would require to restart that calculation, however it would require that all needed data of those other entries is still held. But that is, by design, not the case.
In other words, the later change of entries in a rrd4j database is (IMHO) is not possible.
Note: I am a fan of rrd4j , but not a developer of it. So I migth be wrong here.
I understand that, and I am using the third approach from that very post well enough but if there were a native way to detect the source in rules I could eliminate having so many duplicate proxy items or engineering a different workaround for functionality that should be native to the system. For example:
if (item.receivedCommand.source == BINDING) {
// our command was a manual request
}
else if (item.receivedCommand.source == API) {
// our command was received over API, so some sort of UI
}
else if (item.receivedCommand.source == ESH) {
// our command was internal to the ESH runtime, so a rule
}
is a much more elegant solution than having to have to keep track of five proxy items manually or hacking something together with timers or tons of groups or some other manual approach and less prone to error.
I’m not arguing against the request. I’m just presenting approaches that future readers of this thread can use until it does get implemented as part of the core. I just don’t want people to think that the requested feature is simply impossible.
@opus
Assuming that RRD4j follows the same basic tenants as RRDTool for generating RRD’s then it doesn’t need to re-calculate the results if you change the data. Data should only require re-calculation at rollover.
And perhaps I misled by saying ‘enduser’, and by that I meant someone like myself who is not a developer, but runs their own OH2 system at home and is familiar with the setup, installing from scratch on a linux or other OS machine, setting up mosquitto, etc.
