I would really like to be able to write tests for my rules.
So I would imagine having a test environment, where I can mock items, things and triggers, invoke them and do assertions.
I find it rather difficult to write rules without being able to quickly write a test for them.
We can do this in jruby. This works on OpenHAB 3.3+
https://ccutrer.github.io/openhab-jrubyscripting/main/file.testing.html
It does work for sure, that’s why i linked it. I do not want to reinvent the wheel, as i said for inspiration.
The main idea was to create let’s say a blueprint, bom, design, manual of a little device let’s say 20€ range that one can put together with it’s own hands that in the end does
output audio, voice, notifications, states and so on. @JimT already had the idea of also integrate a mic, sure i’m all in for these things.
The goal is to have something that is “open” as in “openhab” not a closed amaphone home box like an alexa or similar. I’m sure there are many people that would love to have a plug and play device that does just that and works with minimal effort. I really like the mycroft mark 2 approach but that is already over the top and too expensive for a little speaker that one can have in every room. There are also a lot of people who don’t want to build themselves or can’t and i’m aware of that but that question can surely be thought of as we progress along and have the thing created =)
My vision behind the idea was that community input, development of the pysical thing itself as well as code development on the openhab side goes hand in hand together from the start.
It could be done in a thread where we have a timeframe for ideas, similar to this thread, poll the best → create.
Then another timeframe for pcb development, oh implementation, writing the manuals and so on.
But that’s already too much detail, let’s keep this thread a wishlist.
Feel free to rephrase my idea, i’m not that good in expressing myself. But i will surely answer a pm if there are more questions.
That being said have some happy days and keep wishlisting 
PS. There are already a lot of great wishes in this thread. Let’s turn them into reality.
Looks nice, but would love to have it in webui and for ecmascript 
Have you had a look at MyCroft https://mycroft.ai/ it has and OpenHAB skill by the looks of it Mycroft AI Skill | openHAB
+1 on more love for sitemap.
My system requires minimal interaction through the UI, so the old sitemap is good enough for me. Just one thing that would make it greater is to dynamically populate a list from an OpenHab items. This simple enhancement would make sitemap so much more powrful.
Yes, i’ve seen it. I don’t need a mic for me personally and the input side of things.
This was added by @JimT and is already ahead of the initial intention from my side.
I’ve been using mimic3 as tts service for quite some time and it’s working fine.
I’m also not trying to build a device that is able to host the whole openhab itself like a mark 2… Think way more simple.
Imagine a little device/thing that is able to output whatever the user wants. A simple cheap low power (Audio + light) “local/offline” output/notification extention to openhab itself that can be added to every room without breaking the bank and still keeps working when there is no internet.
I’m not against adding a mic but i’d start with the output/notification side of things first and add the input/control side of things when the basics are working nicely aka. a later stage.
Correct. The wishlist request is to be able to create bindings via Javascript; rules are the wrong construct for this. I am using a rule currently, because that’s what I have that I could find enough documentation to get where I wanted to go, and was fine until I wanted to go from N=1 to N=2.
I will do some more spelunking through the documentation for library functions. I suspect it wouldn’t give me the flexibility of the thing:channel UI for linking the data items to the functionality, but for two locations, I can deal with that.
It would be really nice of there were way to get the milliseconds directly from a DateTimeType, rather than having to do .zonedDateTime.toInstant.toEpochMillis. Is there a reason why a .millis method could not be added to the DateTimeType API?
@rlkoshak WDYT?
Hello, happy holidays everyone. I really wish Santa would bring me UoM (unit of measurements) support in Blockly. Being able to compare item states to values with a certain unit.
Hello @MathiasVDA,
we are not Santa, but @stefan.hoehn and I will bring this feature to Blockly.
We are currently working on a larger update to Blockly, which will include UoM handling, see Migrate Blockly to JS Scripting (GraalJS) · Issue #1597 · openhab/openhab-webui · GitHub.
Still sounds like santa to me
I find Blockly such an amazing tool, so thank you very much for the work you’ve already put into it and what you’ll dedicate to it in the future!
I don’t personally have a need for this, but I would like to draw attention to how OPNsense does this, which IMHO is the gold standard. Backup is a single file and the restore process is to upload the backup file after which a reboot is triggered and everything is back to how it was before. That is paired with functionality that allows it to track all changes in a git repository and push it to a git server somewhere else on a schedule and you have pretty solid backup/restore mechanism.
As this topic is coming up every time around the time of year for wishlists, some background.
I acknowledge that UI integration for B&R of OH config would be a nice addition, but overall there’s quite some misunderstanding among wishing users why apparently simple demands like backup& restore are not and will not be built the way they keep asking for.
OpenHAB and openHABian are not appliances, in reality home automation systems are way more complex. While we probably all would like things to be that way, truth is you cannot compare OH to simplistic appliances like OPNsense, and it’s very much misleading to call that a standard that would ideally apply to OH as well.
OH is not a monolith but consists of multiple modules, several of these to have their own config, in their own format, because what they need to cover is so much more complex and variable than are simple parameter lists for a VPN or other simple applications.
UI user credentials are part of Karaf which in turn is an externally maintained component so we do not even have influence on how they store their config.
Main UI uses JSON to represent Widgets and OH things+items plus for the latter there’s the old text input format many people still want to use.
Next, think of integrations with Alexa, Homekit and others.
And this is just about OH. If you widen scope to include all of the OS, 3rd party tools, OS and HW configuration are part of the big picture, too.
Persistence data and logs are in this domain, people use various databases for this. MQTT broker config, too.
All of these you cannot force into a single backup file, not even a tar one.
Let alone to mention all the implications of running your OH on Raspi vs x86, Windows or even MacOS.
I wish channel autoupdate for bindings. Currently you have to delete and re-create items manually when new channels are introduced.
I wish there would be an implicit variable for the last trigger time of an item - see here
Happy Holidays!
Fully agreed with you, that would be far to complex and error prone or even impossible.
What I was wishing for was a simple way to backup and restore what a user configures after OH was set up initially, restricted to what todays backup in the CLI can do. So it is about the configuration steps, not about a full system backup with all dependencies.
For me this is e.g. Things, Items, UI, Rules and Scripts, the basic configs done within the OH Main UI and maybe (but not mandatory) including the information what bindings/transformations are active and configured.
So no, not a full backup that can directly revamp OH from scratch on fresh hardware, but just securing the parts where the major effort of the users is being put into.
To me it is a valid wish to be able to secure and restore this in a way as simple as possible.
It is by no means a requirement to e.g. backup user credentials or authentification data required to connect to external portals - this can always be re-done by the users when it is necessary to setup things from scratch - besides that there is always the option to have a full SD card backup at least for a Pi.
No need to track everything and be able run a full revert on the whole system, but just the major things users put effort into. And as there is no underlying Git one can not simply discard pending changes in case he/she broke something which was working - not everybody is a crack in OH right from the start, so things happen.
If we only consider all encompassing backups then a full SD card backup is the road to follow (and even then one may fail), but a config backup of things within OHs domain is something worth to think about.
My impression and experience from many years is that usability is a major key to success - a system may be rock solid and fully functional, but also can die in beauty if it is hard to use for novice or basic users. OH has made huge progress there in the last years.
Such a wish list reflects where pain points are, as everybody can simply tell what is missing for him/her without bashing onto the overall thing.
Finally: If a wish is coming up every time, isn’t it worth (re)considering it?
Just on a side note: There are some situations, only a reboot solved my problems (OH3-versions). So, yeah, sometimes a good ole reboot does help. 
I see your point - and having openhabian-config options available in Web-UI would highly enhance usability - even for advanced users, let alone beginners. Most of the menu-options can be run via Web-UI and amongst the most useful in my eyes are certainly
I think, noone assumes a “one file restores my whole system” implementation, but reducing the number of touchpoints for users to the sytem will increase the overall experience of openHAB greatly.
if you need one: openHABian can create automated amanda-backups for you - or regular SD Card clones. That saved me from re-installing everything once, as I messed up my config backups…
and yes: that’s something I don’t expect on a Web-GUI.
Let me elaborate on that. How can you decide something like this? I assume you are talking about openhabian - you certainly can decide whatever you want.
But the requests we are talking about are to have maintenace capabilities (e.g. backup) in MainUI.
Let‘s take out technologoy here for a moment as this is about user requests and some users simply do not want to be involved in technology.
What I want to say with the bullet points is that it is a process (as always). Why not starting with basic features and add bits and pieces over time.
But to be honest, I do not like your approach to overcomplicate things to use this as an argument of why not do things. Your point would be valid only if users requested this.