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?
I think its JennyNeural voice from Azure? I am not sure as it just works out of the box and sounds very nice and I have no idea how it works, as it just does without any work needed. This is what impressed me the most about HA, that I have a fully setup chromecast that I can type text into and then magically a voice speaks back at me within 20 seconds of turning the system on.
Yes this was my next experience. Camera picture was working much quicker then openHAB, but 45 minutes later I was screaming why it was firing up FFMPEG to create a snapshot from a rtsp feed when my camera was ONVIF and i set it up with ONVIF integration and I know my cameras all support snapshots out of the box via ONVIF. Then I screamed about how hard it was to move a camera around due to lack of documentation.
The recommended addons at this time are only rrd4j, basicUI and jsscripting. We can easily add to that in the setup wizard code. But I don’t think recommending something that requires extra configuration (like setting up an account) without taking the new user there is an improvement. I am less concerned about it for suggested addons.
Therefore, I think we should be more explicit about recommendations with separate steps for each major recommendation and show options and have config flow for each:
- persistence
- rules engine
- weather service
1 Like
What about non-preselected suggested addons, with a link to addons store for more, but still a part of the initiall wizard.
BTW What’s the criteria for showing the initial wizard, so I can wipe out my installation and start over?
It will run on initial setup, but you can always force it with: http://yourOHServer:8080/setup-wizard/. At the end of wizard execution, the main UI overview page is created. Once that exists, automatic starting of the setup wizard will not happen anymore.
1 Like
Thanks! I’ve just tried it. So all the setup wizard does is suggest addons and create an empty overview page?
Plus the basic regional settings. So, at the moment, yes, that’s what it is. I see a lot of opportunity for improvement here though, to make that initial setup smoother and leading to something which is closer to actually doing something.
Improvements should probably be done in small steps though, not trying to do everything in one go.
8 Likes
I don’t know if it is possible, because I am currently only using the Smart Meter Bindung with an IR head on my Power Meter, but many people have interest in Power consumption / production.
Maybe we could auto disvover some Solar system Information.
But I agree, that most of the starting with smart home has something to do with controlling lights, smart wall plugs and maybe shutters.
To show the user that he can control his lights with openhab in under 10 minutes after the setup should be the prioritized task.
I also think that the idea to show the server host machine information is great for a first experience. Not really helpful, but look at how many advanced users of selfhosting stuff at home are using ‘homepage’ with the current memory usage etc shown.
This should be some easy Information to gather for a first dashboard.
I don’t know if openhab wants to follow the same strategoy, but I think it is cool that HA is adding more and more cities to there gargabe calendar notification feature. I don’t know exactly where I saw it, and maybe it wasn’t HA official, but it is easy for everyone to select there city and street to get these information in a few minutes. Maybe it was in HACS.
And isn’t there a feature to track the app users if they are at home by default?