I like the metaphor. Everyone drives, even the mechanics and engine designers. We need more people owning and driving OH, in the hope that some of them are also makers, mechanics, tinkerers who will create more accessories for our beloved car, and for third parties (light bulbs, devices, IOT) to design their products to support OH
4 Likes
Just to put the record straight: The setup wizard shows a list of recommended and suggested addons pre-selected. The user can select extra or remove the pre-selections. The suggested addons come from the addon finders. The recommended addons are definened in the web UI code of the wizard and are: basicUI, jsscripting and rrd4j. If the user does not change the pre-selection, recommendations and suggestions is what gets installed.
It would be quite easy to add mapdb to this recommended list. However, it possibly would make things clearer to make this a separate stap in the wizard to select persistence with the 4 options presented and further exclude persistence selection from the addons. One little thing though: if services like influxdb are running on the hardware of OH, they could be found and offered as a suggestion as well. So that would need to be considered.
3 Likes
Great idea!
Astro is easy once the user has setup location.
MapDB would really help new users, since they usually wonder why there switches etc aren’t restored after restart and there is some confusion about RRD4J.
For OpenWeatherMap, we’d need to redirect the user to create an API key, which then could be entered in the setup wizard, and then the OneCall Thing could be automatically added (I guess this is the most useful one).
Package support has been removed in favour of the setup wizard doing the installation of bindings.
So no matter what is done, the setup wizard would need to request the add-on installation via REST.
IMO we should make the configuration explicit by having the setup wizard create a persistence configuration which can later be edited in the UI.
The implicit store configuration of RRD4J if there is no config also causes some confusion.
If we remove the default behaviour of RRD4J if there is no configuration, then install both RRD4J and MapDB with the setup wizard, and create their configs (so they are UI-editable).
Then use only MapDB for restore and RRD4J for graphing, that wouldn’t be a bad solution IMO.
I still have MapDB on my production system for restore, and InfluxDB for graphing and rule.
2 Likes
I was thinking that we edit persistence settings within the item editor. It seems a lot more cohesive that way rather than separately.
In the item editor, it would have a link for “Persistence” that leads to a pop up for a more detailed option. In there, give people the option of which persistence service, and the strategy for that item.
1 Like
Apropos the magic experience… it seems to me that the most magic would be if OH initialises with a few good things working perfectly, rather than initialising with a whole load of everything that requires special initialisation and looks confusing. Less is more! KISS!
5 Likes
I agree, we don’t need to install esoteric stuff. The experience that a new user should have though is that they should be able to control their lights, fans, smart switches/plugs, and TV maybe, straight out of the box.
They’d get some sort of UI where they can control their devices. Basic UI would be easy both in terms of programmatically creating it, and in terms of using it.
On that note, MainUI could probably display a QR Code, that the Android (and ios) app can scan. The QR Code:
- Link to download the android/ios app
- Setup data that contains the server name and whatever else needed for the App to connect to OH. That would be a really slick experience.
Then the next step is to guide them, or make it obvious how to create rules / automation, so time based + sunrise/set.
It would also be cool to be able to create rules using the App. @mueller-ma
Everything else, like graphing etc would be a bonus but most people are more interested in what they can “do” with, or what OH can do for them.
4 Likes
I’ve never had a user not know they were using InfluxDB. Prior to OH 3 I never had a user not even know they were using a specific add-on.After rrd4j came by default though I have seen many users who were not even aware rrd4j existed.
My main point is it seems a really small thing to present to the user “hey! we recommend these add-ons and this is why” as part of that first start wizard, maybe with a few key ones like Astro and rrd4j preselected by default, and with the option to not install those is a small burden on the end user who just want something now, informs all users that add-ons exist and what some of them do, and gives them some choices on where to go. Even if you don’t give them a choice, I think it’s better that anything that gets done on behalf of the user (e.g. add-ons installed) is clearly communicated both what and why to the user. Don’t just blindly install a bunch of stuff silently.
Having that first run wizard does that plus it gives the option to customize it. It seems like a win-win with minimal overall cost to the first run experience.
That’s what I’ve been trying to say put much better.
This is certainly more doable now than it once was now that we have managed persistence configs. But we can’t lose the ability to set default strategies that apply to all Items too.
It gets complicated though when you need to address which lights, fans, et al. A KNX experience is going to be vastly different from a Hue or a Zigbee experience. But all three control lights.
This would be great to add to the startup wizard.
5 Likes
This is what I was thinking too, but I see that it wasn’t clear. I was more concerned about shifting the focus to be on the behaviour, and that came across as blind installing. Rather, users should know that RRD4j and MapDB are being installed to provide the persistence behaviour they want, and after that many of them would never need to think about it again.
3 Likes
I thought about this as well, but it would be some work and you can already view Main UI in the app where you can edit the rules.
What about rule templates?
There’s a nice sunrise simulation template to control lights among others which would and if given some ideas I can quickly code up some more simple ones. The one’s I’ve written so far tend to be complicated and generic and probably don’t make a good “first look” at rules but I can quickly create some more and even use Blockly (I think) so once instantiated the end users can see how they are built.
I just need ideas on what to create which would be appropriate for a first time user.
It might be a nicer intro to rules to be able to install and then see how they work than to throw them feet first into writing from scratch. Though they will need to have some Items defined before that point.
2 Likes
I’m just getting my feet wet with Blockly, and found some of the rule templates to be overwhelming. It’s not that I don’t understand them–it’s just a lot to process visually all at once.
So, the first rule I made in Blockly is super basic. It takes in the value of the triggering item and converts it to title case.
There are probably better ways to accomplish this task, but it was more about about tackling something with very few moving parts so that I can get comfortable with the Blockly mechanics. I’m not suggesting this as a template–it’s more about having templates with minimal blocks.
I should note that this was actually my second version. My first one called the state of a specific item in order to update that specific item. I then changed it to use contextual info so that it will work with any string item I add as a trigger. That taught me how to go from “do something to a specific item” to “do something to any item”.
As far as I’m aware, there are only one or two templates that use Blockly in the first place.
Until now, I personally have approached rule templates like the Wizard of Oz: “Don’t look behind the curtain!” You shouldn’t really need to look at the code for a template, just the parameters and what they mean. For example, take Debounce [4.0.0.0;4.9.9.9]. All the end users needs to see is:
How it’s implemented doesn’t matter.
However, I’m proposing some rule templates that are instead intended that the code is looked at by the end users. So instead of focusing on error checking and robustness the focus would be on simplicity and adding comments and explanations on how it works. But because they need to be relatively simple, they can’t really do all that much, though they probably need to do more than changing a String to title case. Coming up with what that might be is my challenge right now. My rules have been honed and rewritten for years and frankly, about 80% of my rules are now implemented as rule templates (that’s where I came up with them) and the rest are not really generic. If I had ideas from my personal config I’d probably have already implemented them as templates. 
1 Like
How about a teaching rule that has progressively more complex ways toggling a switch item.
- Send a command to an item (to serve as a baseline equivalent to a simple UI rule)
- Send a command after a delay
- Send a command with an if condition (“if it’s Tuesday”)
- Send a command with multiple conditions (“If it’s Tuesday or the 1st day of the month”)
- Send a command with an if/else condition (“ON if it’s Tuesday, OFF if it’s Wednesday”)
Only the first version would be enabled by default. The user would have to disable it and then enable the latter versions to see how they work.
I suspect that these five examples would cover about 70-80% of my rules. 
1 Like
The problem with 1 is that a Script Action wouldn’t be the appropriate approach. A simple UI rule without any code, not even Blockly, would be the appropriate way to do that. The same goes for 3. One could argue that 5 would best be implemented using two simple UI rules, one for Tuesday and another for Wednesday.
Only 2 and 4 cannot be done with simple UI rules, 2 because there is no “delay” action and 4 because simple rule conditions don’t support days of the month.
I don’t like the idea of creating an example or examples that doesn’t show the most appropriate way to implement something, even if it’s only for instructive purposes.
Also, turning on/off a light based on a schedule is not very compelling when it comes to automation. I feel like we need more “wow” that shows off a little more automation and interaction between stuff that normally wouldn’t be able to interact or does something that the typical apps that usually control the lights cannot do.
Maybe something like Presence Simulation [4.0.0.0;4.9.9.9], or Virtual Solar Light Sensor [4.0.0.0;4.9.9.9], or Smart Doorbell only in blockly.
just a suggestion…
turn on the porch light when it gets dark… simple
Why I think this is a good first rule:
I think a lot of people get interested in home automation initially playing with smart lights. I think next to google/alexa smart lights are a common entry point.
Shows the power of openHAB and introduces the astro binding. A binding everyone can install, needs no hardware. The light doesn’t just turn on at 6pm. The system actually knows when it gets dark and adjusts when the seasons change… magic
lesson 2… turn light off at 11pm
get em this far and they’re hooked
edit: by the way JimT, great topic, great discussion, lots of really great ideas and big thanks for all the folks who have recently worked hard making the new/first time user experience better.
6 Likes
I was suggesting it to communicate to users that the two approaches are the same thing, and then build upon that. It was more about making the leap from UI to Blockly and connecting the dots, but I acknowledge that it could confuse users as to the best way to do it.
The important thing to me is the progression. It’s just a little more meaningful (to me) when it’s actually hands-on in the system than a tutorial or video.
1 Like
+1 this is what I envisioned too. We don’t want to info dump on the first date.
3 Likes
The “when it’s dark” part is the challenge. We can’t count on them having a sensor and the calculations to do fake it based on solar radiation and cloudiness, while not super complex, are probably more complex than appropriate. See Virtual Solar Light Sensor [4.0.0.0;4.9.9.9].
If we just mean based on sunset, that’s pretty easy. But that doesn’t need a script to accomplish. That’s just a simple UI rule with no code, blockly or otherwise.
If we just want something like that, then turning on a light at sunset and off at a fixed time would be the way to go. It could either be two rules:
configuration: {}
triggers:
- id: "1"
configuration:
thingUID: astro:sun:local
event: START
channelUID: astro:sun:local:astroDusk#event
type: core.ChannelEventTrigger
conditions: []
actions:
- inputs: {}
id: "2"
configuration:
itemName: FrontPorchLight
command: ON
type: core.ItemCommandAction
and
configuration: {}
triggers:
- id: "1"
configuration:
time: 23:00
type: timer.TimeOfDayTrigger
conditions: []
actions:
- inputs: {}
id: "2"
configuration:
itemName: FrontPorchLight
command: OFF
type: core.ItemCommandAction
Or if we want to have some blockly involved combine the two into one:
configuration: {}
triggers:
- id: "1"
configuration:
thingUID: astro:sun:local
event: START
channelUID: astro:sun:local:astroDusk#event
type: core.ChannelEventTrigger
- id: "2"
configuration:
time: 23:00
type: timer.TimeOfDayTrigger
conditions: []
actions:
- inputs: {}
id: "3"
configuration:
blockSource: <xml xmlns="https://developers.google.com/blockly/xml"><block type="controls_if" id="3bp[qw/{m,Rsbex1V~md" x="139" y="117"><mutation else="1"></mutation><value name="IF0"><block type="oh_zdt_compare" id="F~h[,td/kaN)$wd4KbuG"><field name="operation">before</field><field name="dateComparison">time</field><field name="precision">seconds</field><value name="zdtOne"><shadow type="oh_zdt" id="^VH~6bGwM-mpgL_e8uRZ"><field name="day">2024-02-22</field></shadow><block type="oh_zdt_now" id="]d|p2g~Gz^%PgID}tZ~0"></block></value><value name="zdtTwo"><shadow type="oh_zdt" id="Xl8K=wia.q:*U0xLZIgA"><field name="day">2024-02-22</field></shadow><block type="oh_zdt_fromText" id="F/3AZDDZ/-ISY.[FSf@9"><value name="day"><shadow type="text" id="(Kyt,C9PmeAUsX`nH;Hf"><field name="TEXT">2024-02-22</field></shadow><block type="text" id="^0P2`r8$|L{Fm]7R6g-Z"><field name="TEXT">23:01</field></block></value></block></value></block></value><statement name="DO0"><block type="oh_event" id="/jQuOyN4I6JUzFP]9CiB"><field name="eventType">sendCommand</field><value name="value"><shadow type="text" id="AxIc(+~PG|i*Y$DZy$K*"><field name="TEXT">value</field></shadow><block type="text" id="-P[E%.Be-tG)XR(=C,Mi"><field name="TEXT">ON</field></block></value><value name="itemName"><shadow type="oh_item" id=")5YgIY_^jwndUnvwSW|J"><mutation itemName="MyItem" itemLabel="MyItem"></mutation><field name="itemName">MyItem</field></shadow><block type="oh_item" id="sA_8`hv3ME++|m|5*2%/"><mutation itemName="FrontPorchLight" itemLabel="Front Porch Light Switch"></mutation><field name="itemName">Front Porch Light Switch</field></block></value></block></statement><statement name="ELSE"><block type="oh_event" id="Dyi0=8vs{6-d`MJ9!p8["><field name="eventType">sendCommand</field><value name="value"><shadow type="text" id="AxIc(+~PG|i*Y$DZy$K*"><field name="TEXT">value</field></shadow><block type="text" id="cR$5aK@ux@Kfwa3YJ:o]"><field name="TEXT">OFF</field></block></value><value name="itemName"><shadow type="oh_item" id=")5YgIY_^jwndUnvwSW|J"><mutation itemName="MyItem" itemLabel="MyItem"></mutation><field name="itemName">MyItem</field></shadow><block type="oh_item" id="B[}IaV1Lk}BRgsHjD85F"><mutation itemName="FrontPorchLight" itemLabel="Front Porch Light Switch"></mutation><field name="itemName">Front Porch Light Switch</field></block></value></block></statement></block></xml>
type: application/javascript
script: >
// graalVM
function zdtCompare(zdt1, zdt2, compareOp, precision, compDate) {
switch (precision) {
case 'years':
zdt2 = zdt2.withMonth(zdt1.monthValue());
case 'months':
zdt2 = zdt2.withDayOfMonth(zdt1.dayOfMonth());
case 'days':
zdt2 = zdt2.withHour(zdt1.hour());
case 'hours':
zdt2 = zdt2.withMinute(zdt1.minute());
case 'minutes':
zdt2 = zdt2.withSecond(zdt1.second());
case 'seconds':
zdt2 = zdt2.withNano(zdt1.nano());
}
if (compDate === 'date') {
zdt1 = zdt1.toLocalDate();
zdt2 = zdt2.toLocalDate();
} else if (compDate === 'time') {
zdt1 = zdt1.toLocalTime();
zdt2 = zdt2.toLocalTime();
}
switch (compareOp) {
case 'before':
return zdt1.isBefore(zdt2);
case 'equal':
return zdt1.equals(zdt2);
case 'after':
return zdt1.isAfter(zdt2);
case 'beforeEqual':
return zdt1.isBefore(zdt2) || zdt1.equals(zdt2);
case 'afterEqual':
return zdt1.isAfter(zdt2) || zdt1.equals(zdt2);
}
}
if (zdtCompare((time.ZonedDateTime.now()), (time.toZDT('23:01')), 'before', 'seconds', 'time')) {
items.getItem('FrontPorchLight').sendCommand('ON');
} else {
items.getItem('FrontPorchLight').sendCommand('OFF');
}
type: script.ScriptAction
Blockly:
Either can be made into a rule template. However, rule templates cannot change the rule’s trigger through a parameter so the trigger at 23:00 can’t be a parameter.
3 Likes
To think outside the box and offer another way for consideration…
We are offering a list of discovered bindings to the end user, why not offer a list of “highly recommended” or “commonly used” bindings at the same time as the discovered bindings? They could be pre ticked to install, then a user can u tick any they do not like.
I would love it if I had a list of commonly used and discovered bindings all listed on the same page, I tick what I want, then press a single “install selected bindings” button. After pressing I walk away and make a coffee whilst they automatically install and the screen can recommend reading a new user guide whilst they install. We do not have to do anything the same way as HA, we can come up with our own way of doing things. I do however really like that with home assistant you instantly have all your Chromecast working in a ready setup widget on a page and you already have text to speech working to test the Chromecasts out with.
Fantastic, I really should find the time to trial it out as a new user soon then. If it auto selects basic bindings that >30% of users will want, then that keeps me happy.
How does HA do TTS?