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!
2 Likes
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.
2 Likes
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.
1 Like
I wish channel autoupdate for bindings. Currently you have to delete and re-create items manually when new channels are introduced.
1 Like
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?
9 Likes
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
- upgrade system
- backup/restore the OH-config (though it could be like >250MB) and
- installing/removing/using little helpers
…
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.
4 Likes
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.
2 Likes
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.
- Does it make ANY difference for the USER that OH is not monolithic and consists of several components? NO
- Does any user expect to have a perfect working backup tool that covers all aspects of various backup strategies? NO
- Does any user expect to have a backup tool in place that covers the COMPLETE scope you mentioned (all of the OS, 3rd party tools, OS and HW configuration, persistance, etc)? NO
- Is MainUI at the same level of finalisation as you are demanding in your post for a GUI based backup? NO! Does anybody complain that it is not finalized? NOT at all! We all love the MainUI.
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.
7 Likes
not sure if I get you right but you could execute the following command from within MainUI:
sudo /usr/share/openhab/runtime/bin/backup
It does not even require Amanda to install. at least you can link this to a button and do a backup whenever you require it.
2 Likes
Proper Python 3 support will only be possible with HABApp since it’s the only add-on/rule engine that uses the official python reference implementation.
I get that it might be overwhelming at first but there are many examples in the docs so even if you are a novice (and we have a couple of novice users with HABApp) it’s just copy paste.
Additionally HABApp has very (!) nice tracebacks so any error will be logged properly and if you are stuck you can just ask for help in 3rd party.
Of course it’s different than jython with the helper libraries so you have to be willing to learn something new.
3 Likes
This is a pet peeve of mine. You shouldn’t be using epoch. There is almost no need to. It makes your code longer, harder to read, and harder to maintain.
I have yet to see a case where using epoch is better than using the ZondedDateTime and Duration Classes.
As for adding that to DateTimeType, that would only fix a minority of places where time is interacted with and it would create an inconsistency. You would still need to get the instant for now and any other time you get a date time outside of the state of the Item.
But I’ll say it again, there is never a reason (I’ve encountered thus far) where messing with epoch is shorter, easier to understand, or easier to maintain. So I would encourage you to explore what you can do with ZonedDateTime and Duration.
Probably not the answer you were hoping for. But compare the two and decide for yourself (here in rules DSL but the overall should apply to all the langauges:
var deltaMillis = now.toInstant().toEpochMillis() - (MyDateTime.state as DateTimeType).getZonedDateTime().toInstant().toEpochMillis()
var deltaMillis = Duration.between(now, (MyDateTime.state as DateTimeType).getZonedDateTime()).toMillis()
There is an issue open for this I believe.
I wish for HomeKit emulation, i.e. exposing openHAB as a HAP Client, allowing openHAB to control Homekit devices. Some details here:
My current use-case is being able to integrate with my Velux Active gateway (locally), so that I can control my skylight windows, and perhaps more importantly, lock and unlock them according to presence state (currently this requires pressing a physical button when leaving and entering the house).
1 Like
I’d have some interest in working on this, but it’s pretty low on my own personal priority list.
3 Likes
Tabbed pages could need some love
Examples:
- Unlike other pages they are missing the Crtl-R “Run Mode” - to see how they end up you have to add them to the menu.
- Their design is very different from the design of the standard widgets you add to them
- I would love to see some documentation on how to style them, maybe some more settings for the tabs page or on individual tab
- The Page Configuration parameters contains nothing. Maybe fill with some default settings to show what is configurable?
Widgets/cards
(I don’t understand the terminology here, widgets and cards seems to be the same thing?)
When I add a widget to a page these are the standard widgets:
(This list should be sorted, BTW)
Compared with the component reference (Component Reference | openHAB), I would like to see:
- Button
- Chart
- Icon
- Link
- Trend line
- Some simple “text label” to be able to place text anywhere
It would be great if they matched the default layout.
Some of the cards (especially oh-label-card), it would allow greater flexibility if they removed empty space when you skipped the footer or title.
2 Likes
All cards are widgets but not all widgets are cards. There are also Cell widgets and List Item widgets. Each are used in different ways/contexts.
Many widgets cannot be placed on a page on their own. They have to be included as part of another widget. All the List Item widgets fit this category. I believe this list also are widgets that cannot be placed on a page on their own. This is why they are not listed.
Thanks @rlkoshak!
Playing with e.g. oh-button in the “code” lets me place it as a component in a oh-grid-item in exactly the same was as e.g. oh-toggle-card. It works, but the aesthetics look out of place.
grid:
- component: oh-grid-item
config:
h: 1
w: 3
x: 0
y: 2
slots:
default:
- component: oh-button
config:
text: Middag
icon-f7: exclamationmark_circle
action: rule
actionRule: 27afc0a3-b898-46ad-acc9-e4a7541dcc22
large: true
class:
- display-flex
Example of a coded button (on top) vs a proper card on the bottom:
I believe adding for example an “oh-button-card” widget which had a design which aligned with the other system widgets would make it easier for normal users to design pretty pages.
1 Like
Ha ha. I wouldn’t have bothered to ask if I knew in advance what your answer would be. You always have a good perspective which is why I ask your opinion.
I see your point about consistency, but DateTimeType is not a Java class; it’s an openHAB class. So I would argue that adding a toMillis method would not be inconsistent.
Yes, exactly, the first one is kind of nasty. That’s my point. But if you add a toMillis method to `DateTimeType, it becomes (3rd line below), which is shorter, and just as easy, if not easier, to understand.
var deltaMillis = now.toInstant().toEpochMillis() - (MyDateTime.state as DateTimeType).getZonedDateTime().toInstant().toEpochMillis()
var deltaMillis = Duration.between(now, (MyDateTime.state as DateTimeType).getZonedDateTime()).toMillis()
var deltaMillis = now.toInstant().toEpochMillis() - (MyDateTime.state as DateTimeType).toMillis()
Note, I’m not arguing against adding a toMillis() to DateTimeType. I’m arguing that, at least IMO, if you are using epoch in your rules, you are doing it wrong. (That’s probably more strongly stated than I really feel, but it is irksome when I see it on the forum. It’s like seeing someone try to code in a Fortran style in Python, anachronistic).
The inconsistency would be in use. When I have a DateTimeType I can just call toMillis() but when I have a ZonedDateTime I have to get the Instant first which means I have to remember two different ways to get to epoch and have to keep track of which to use in which context.
As it is now, there’s only one way which is to get a ZonedDateTime and get the instant and then epoch, so only there’s only one way to remember.
Until you need seconds, minutes, or even HH:MM:SS.mmm, care about the absolute value of the duration, etc. The raw millis are almost never all that useful to humans who might be seeing these values so they are either going to need to be converted anyway (or converted back to a ZonedDateTime) or they are only used in a calculation. And even in cases where it’s only used in a calculation, Duration.parse('PT5M15s') (or `Duration.ofMinutes(5).plusSeconds(15) if you prefer) is a lot easier for the human to read in the code than 315000 (5 minutes 15 seconds).
The human already has to hold a lot of stuff in memory to understand code. Why make them do math they don’t need to? The mere fact that the human has to mentally divide by 1000 (and perhaps again by 60) to know what the millis represents (whether it’s the result of a calculation or reading and understanding the code itself) makes working with epoch and millis directly inherently more difficult to understand, even if toMillis() were added to DateTimeType.