Triggering a rule when user navigates (back to parent level) in Basic/Classic UI

[Charly61 (Charly Clément)]

Dears,

I would like to receive an event in a rule, when an user navigates on the UI, typically when he “go back” from a form to its parent form.

I use sitemap, items, and rules, nothing else.
My goal :
In a “sub-form”, I want to edit some parameters, and finally validate them with an “OK” button.
This button is a Number, visible as soon the user changes on of the parameters.
(by a rule setting it to 1)

Clicking on the button trigger a rule which save parameters, and put the Number to 0; all is ok.

But if the user aborts its changes, by returning to the parent page, I need to be informed, to clear my Number.

All of that seems so trivial that I am surprised that I found absolutely nothing across the whole internet about this topic!??
Or do I misunderstand something??

Thanks a lot for your answer.
Charly.

[rlkoshak (Rich Koshak)]

@Charly61

All of that seems so trivial that I am surprised that I found absolutely nothing across the whole internet about this topic!??

Given the current capabilities of OH and its architecture, this is not trivial. This is actually quite difficult to impossible and is actually a fairly unusual use case for OH.

First of all, there is no event that gets created when a user navigates in the UI so there is nothing that can be used to trigger your checking rule.

Secondly, when the user makes changes on the UI, each change is transmitted to OH as an event, usually a command, as it is being made. There is no concept of a transaction like you are describing.

Thirdly, typically one constructs their UI in such a way that an invalid configuration is not possible so there is no reason to need to validate the settings before putting them into effect. This is partly because there is no way to define free-form text entry. You can use SetPoints for which you set a min and max, a Slider which goes from 0 to 100, a Selection or Mappings which let the user select from a set collection of responses. One can further narrow the possibilities using visibility to only show elements that are valid based on the state of certain Items.

I can see a way one can potentially appoach something like this.

• Implement a proxy Item for each setting.
• Add a Switch Item which the user must click to trigger the settings validation.
• When the Switch Item is triggered, it activates a rule that checks the values of all the proxy Items.
• You need a rule that triggers any time that any parameter is changed to set an Item to ON or 1 which the sitemap then uses as a visibility check to show the OK button.
• There is no way to be informed when the user returns to the parent page so the best you can do is use a timer that goes off after a longish time after the last change to a proxy item without the OK button being triggered.
• You will have to get creative in how you inform the user that the validation failed.
• Finally, when the settings pass the validation, transfer the proxy Item settings to the “real” Items that get used by your system.

[Charly61 (Charly Clément)]

Thank you Rich for your answer.

Aiiieeee, I admit that I am quite disappointed by the “poor” functionalities offered to user by openHAB, compared to the complexity of the “gas plant” which is the software.

Just doing a dummy thermostat user interface seems to be too much complicated for having confidence to go forward with this software.

I just give a look of what I did :

Here, the panel dedicated to a thermostat. This is OK for me, friendly, simply configurable by sitemap.

The functionality is :
In “AUTOMATIC” mode, my system transmits set-points to the thermostat on the basis of the configuration of a “day/night” periods (configurable in “Reglages/Horaires”) and a “day/night” temperatures (configurable in “Reglages/Temperatures”).
How configuration it works :

1. enter in Reglages/Horaires
   

2. enter “beginning of the day period”
   

3. as soon I modify a Setpoint, OK/CANCEL appears
   

4. when happy or not, I push OK or CANCEL
   This action updates (or not) the variable storing the actual valid time
   

But from here, things go wrong!

Below are the misc. config elements used,
just to handle one parameter !
of just one dummy thermometer !

Remarks:
Perhaps I missed something basic !?

• I cannot conceive another way than “OK/CANCEL” to handle safely user parameters and parameters consistency, mostly regarding the poor UI components available.

• My master keywords are Modularity, Genericity, Coherency, and simplicity (if possible).
  I let you imagine my problem when I have to dispatch configuration elements across 5 different files, configure thousands of rules / triggers without having the slightest notion of ARRAY and OBJECT,…

That being said :
In few time, I discovered z-wave, raspberry, z-wave thermostat and relay, and I agree that in very very few time, I had my devices binded and running with openHAB.
In very few time I had a simple interface (with android app) with which I communicated with my thermostat.
That is very efficient and simple.

Question
What is the best solution to keep only the basis of the system, the bindings and the related “drivers”,
and to do all the automation aspects and visual aspects with … netbeans, by example, or an equivalent of .NET / ASP.NET, or C/C++ in multi-threading environment (for automation) ?

Make sense !?

Excuse me if I was a little “critic”, I don’t master very well English (at least in diplomatic aspect)

But respect !!! for a so huge system.

Regards,
Charly.

sitemap:

Text label="Horaires" icon="time"
{
   Text item=Indoor_Time_Jour_str icon="sun"
   {
      Setpoint item=Indoor_Time_Jour_HR_nb minValue=0 maxValue=23 step=1
      Setpoint item=Indoor_Time_Jour_MN_nb minValue=0 maxValue=55 step=5
      Switch   item=Indoor_Time_Jour_SetOK  mappings=[2="OK", 3="CANCEL"] visibility=[Indoor_Time_Jour_SetOK!=0]
   }
  ...
  ...

Variables:

Number   Indoor_Temp_Jour          "Temp. Jour [%.1f °C]"          <temperature_hot> 
String   Indoor_Time_Jour_str      "Début Horaire Jour [%s]"       <time>  
Number   Indoor_Time_Jour_HR_nb    "Heure  [%02d]"                 <clock> 
Number   Indoor_Time_Jour_MN_nb    "Minute [%02d]"                 <clock> 
Number   Indoor_Time_Jour_SetOK    "[]"          

Triggers

rule "Thermo Indoor Handle Indoor_Time_Jour modification"
when	Item Indoor_Time_Jour_HR_nb changed
	or  Item Indoor_Time_Jour_MN_nb changed
then
	Indoor_Time_Jour_SetOK.postUpdate(1)
end

rule "Thermo Indoor Handle Indoor_Time_Jour OK/CANCEL"
when 
	Item Indoor_Time_Jour_SetOK received update
then
	if(Indoor_Time_Jour_SetOK.state == 2)
	{
		val String tmp = Indoor_Time_Jour_HR_nb.state.format("%02d") + ":" + Indoor_Time_Jour_MN_nb.state.format("%02d")
		Indoor_Time_Jour_str.postUpdate(tmp)
		Indoor_Time_Jour_SetOK.postUpdate(0)
	}
	if(Indoor_Time_Jour_SetOK.state == 3)
	{
		Indoor_Time_Jour_SetOK.postUpdate(0)
	}
end

[rlkoshak (Rich Koshak)]

First of all, openHAB is an opensource project. So any “poor functionalities” is because no one has yet volunteered their time to implement it. And like I said, your approach is not typical for users of openHAB.

Secondly, the “H” in openHAB stands for “Home”. It is not designed or architected to be an industrial control system. It therefore lacks the kind of redundancies and checks that one would put in place for an industrial system.

Thirdly the ‘A’ in openHAB stands for “Automation”, not “Control”. What you are trying to do is control your home automation system, not automate it. Rather than setting a set schedule, why not let your heating system work based on events? For example, when OH detects you are home and the sun has risen set to a certain temperature rather than a set start and stop time.

There is a known lacking in OH sitemaps of a calendar picker so that is part of the problem. But there is a larger effort to implement a scheduler and I think the maintainers are waiting on that to be done before tackling the addition of a calendar element to sitemaps.

@Charly61

when happy or not, I push OK or CANCEL

So why do you have this requirement? What would happen if you just let the values update as you click the up and down arrows? You are just setting a time so it is not like you will put your heating system into some bad state while you are adjusting the times. And even if you were, there are simpler ways to handle this (e.g. keep using a proxy but use a Timer to not update the “real” element until the proxy remains unchanged for a certain period of time).

@Charly61

I cannot conceive another way than “OK/CANCEL” to handle safely user parameters and parameters consistency, mostly regarding the poor UI components available.

This is a Home Automation system that does not support entry of arbitrary data through the existing Sitemap based UIs. What exactly are you trying to protect against that you can’t do through properly defining your sitemap in the first place or through a Rule?

For an example of a typical way one deals with heating in openHAB see Heating Boilerplate - A Universal Temperature Control Solution with Modes.

@Charly61

My master keywords are Modularity, Genericity, Coherency, and simplicity (if possible).

I let you imagine my problem when I have to dispatch configuration elements across 5 different files, configure thousands of rules / triggers without having the slightest notion of ARRAY and OBJECT,…

First I would recommend reviewing the Design Pattern postings. There are plenty of constructs and approaches to doing all of this in a sane and simple manner. In particular, Design Pattern: Working with Groups in Rules, Design Pattern: Separation of Behaviors, and A State Machine Primer with HABlladin, the openHAB Genie.

Secondly, look into the JSR223 add-on which lets you write Rules in Jython, JavaScript, or Groovy.

@Charly61

What is the best solution to keep only the basis of the system, the bindings and the related “drivers”,

and to do all the automation aspects and visual aspects with … netbeans, by example, or an equivalent of .NET / ASP.NET, or C/C++ in multi-threading environment (for automation) ?

Have you looked at HABPanel? It is more flexible in many ways and supports the use of custom widgets which may support the additions of the features you feel are lacking.

openHAB supports a full REST API so you can theoretically do pretty much everything outside of OH if you desired. It will be a whole lot of work but you could implement your own UIs and Rules Engine if that is your desire. I know of no one who posts on this forum who does anything like that though. There is also support for MQTT which lets you bridge between OH and something like Node-Red.

But to be clear, Rules are multi-threaded, Turing complete, and if coded using the Design Patterns I’ve sited above perfectly capable of producing generic, flexible, and reusable rules.

And again, I’ll ask, WHY? Why go through all of the effort of creating a transaction out of setting a time? Why set a time in the first place?

[Charly61 (Charly Clément)]

Hi Rich,
Thank’s a lot for your answers.

I effectively come from the industrial electronics/automation world.
(special machinery, hard real-time, rt-fieldbus, “luxury swiss-made” man machine interfaces, dating from the good old time when customers had enough money to pay big specific developments. )

About the « Heating Boiler Plate : Universal Temperature Control » :
That’s exactly what I did, with the difference that times and temperatures for the different modes are configurable by the user. My modes are day, night, (the automatic mode), away, and manual. In automatic mode, a cron, based on the configurable day time, will send the configurable day temperature to the thermostat. Idem for night. (that’s exactly same as the example).
The « away » mode also has its configurable temperature. The manual mode simply sends the setpoint to the thermostat. In these both modes, day/night cron are « disabled ».

Here, manual mode is selected.

Here, selection of another mode

Here, configuration of the temperatures for the different modes

About my OK/CANCEL for changing an “internal” variable, I agree with you,… although… !?
The goal is to build a string with it, on the OK event, to form a cron expression. A rule, trigerred by that cron, will change the real SetPoint of my thermostat (commutation day/night every Indoor_Time_Night / commutation night/day every Indoor_Time_Day). That’s why I would have prefered that my Hour-Minutes variables having a few consistency when I build my cron parameter.
But that’s only an example, little « academic » I agree.
But I am sure that before tomorrow I will have a more critical use case in which consistency will be necessary.

BUT:
Because of a “professional deformation” ,
I think that I have a logic which is not necessarily compatible with the openHAB philosophy.
I think that you gave me some very interesting links, mostly “Design Patterns” in which I will inspirate me.
I think too that the ways you propose me regarding mqtt , jsr223, are very interesting. I want to investigate that immediately !!!
About REST API, I thought about it, but I still do not want to reinvent the wheel.

I am less “negative” like yesterday. So I want to continue investigating openHAB.
Even perhaps I want to develop modules allowing me to do what it seems missing for me,… but I admit that, coming from C++ and C#.NET Visual Studio,…
It really takes a lot of courage to put hands in maven, osgi, eclipse !!! … beeerk !!!
Two hours to build a system reminds me 30 years ago.

Still thanks.
Charly.

[dr_neersen (Michael Bartmann)]

Just an idea (about “There is no way to be informed when the user returns to the parent page”): If some embedded image loads from a URL, and the image is loaded on demand only if you hit that page (this is how I understood the images), maybe there is something you could exploit? There seem to be some obstacles anyway, e.g. caching of the client might supress reloading. And you would maybe have to keep track of the “click path” by putting some state in virtual items.

It would be complicated though, but there are lots of other fiddling with Exec of Http kind of bindings.

What would you think, could such a “hack” work? (Disclaimer: I’d never go that way myself; I’m well aware that the UI resulting from such an approach would not fit the philosophy of openHAB).

Kind regards, Michael

[rlkoshak (Rich Koshak)]

@dr_neersen

maybe there is something you could exploit?

Not with the current OH architecture. If you hosted a separate server that included the images you could then add in some code to that server to generate commands or updates to OH through OH’s REST API. But by the time you have gone through all that much work, you may as well continue the effort and build your UI over on this separate server or adding a custom widget to HABPanel, though OP explicitly stated they don’t want to use HABPanel.

The problems you site would almost certainly be an issue as well, particularly in the phone apps.

@dr_neersen

It would be complicated though, but there are lots of other fiddling with Exec of Http kind of bindings.

I don’t think this can be accomplished with either of these bindings. Remember that the HTTP binding is basically just an HTTP client, not an HTTP server so it can’t host the image. Exec can run scripts or command line commands so I don’t see what it could be used for to implement this.

@Charly61

I effectively come from the industrial electronics/automation world.

I’ll reiterate that OH is not of that world. Expecting the sorts of features necessary in that world like transactions, rollback, realtime performance, enforced order of processing, input verification and validation, etc. to be available in a Home Automation system like OH is unwarranted. The two are similar problem spaces but the two have vastly different requirements and vastly different consequences when something goes wrong.

@Charly61

The goal is to build a string with it, on the OK event, to form a cron expression. A rule, trigerred by that cron, will change the real SetPoint of my thermostat (commutation day/night every Indoor_Time_Night / commutation night/day every Indoor_Time_Day).

You can’t do that. Time cron triggers are hard coded. You cannot dynamically change them at runtime.

What you can do is use a DateTime Item and schedule a Timer. But again we are stuck back on the problem that OH doesn’t support a scheduler nor does it have a Date/Time picker so this is awkward at best. See the Individual Alarm clock for each Day of week, with adjustable duration for a pretty comprehensive workaround for the lack of a scheduler. You probably don’t need something this complicated.

@Charly61

C#.NET Visual Studio

Is not really all that different from Java development all things considered. You have a much lower barrier to contributing to the code than a non-developer would. I do know getting the development environment up and running is a challenge in and of itself though.

[dr_neersen (Michael Bartmann)]

You are right.
But when I wrote about Exec and HTTP binding, I didn’t expect that those would suffice; I mentioned them as an example for lots of more fiddly solutions which are built uppon them (like my bluetooth l2-ping). I thought about the help of an additional web server (e.g. the nginx-proxy many installations like mine need for security purpose). Still I thought you’d need HTTP to poll that information back into openHAB.
Bear with me; I simply stumbled in this discussion to reflect my understanding of the mechanisms and philosophy involved. (and, needless to say, English is not my mother tongue)

[rlkoshak (Rich Koshak)]

No problems and I welcome your ideas.

[Charly61 (Charly Clément)]

Dears,

I begin to have a relative good feeling with OH.

After having tried scripts (simple *.script), cron, timers, I feel I should not have too much limitation, in writing automation “like I love”.

About limitation regarding Basic UI, I think I can live with. By example, my “navigate back” is about properly solved by canceling an eventual pending modification after a timeout.

In having a “nice” polling threads, “croned” or timer activated, I can about speak of real-time.
… and not being too much afraid for doing about whatever.

Thanks for your good answers / remarks, which oriented me in good ways.
Charly.