Want to detect the "last Event button value Where is it??
Had this working in OH2 but would like to use Blockly, don’t know where the Button Last Event is stored
Help
cds
Your question isn’t entirely clear and it’s missing a ton of context.
What last button event? What binding is this? What is this a screen shot of?
Sorry, barking dog interruptions.
In Openhab 2.0 I had used the button push event value from Hue Dimmer switch to bump up or on/off other lights.
/* Dim Button uses negitive val to lower */
rule " decrease brightnest"
when
Channel "hue:0820:001788471aa2:2:dimmer_switch_event" triggered 3002.0
then
(runningvalue = runningvalue - lightincrement)
sendCommand(FamilyRm_NW_floor_light, runningvalue)
sendCommand(CliffOfc_Wall_Light, runningvalue)
end
Currently when I press one of 4 buttons on the hue I get the following log data?
Identifiersquare_on_square
hue:device:001788fffe471aa2:af098861-3d0a-4094-8838-cff39f99d8bd
Label
Hue dimmer switch 1
Location
e.g. Kitchen
Parent Bridge
Information
With channels
Where is that channel and maybe I need to learn channels in general?
Thanks
Don’t post screen shots of logs.
These logs have to do with Items. I don’t see any events from the Dimmer Switch Event Channel.
Even as far back as OH 2.0 there has been two types of Channels on a Thing. A State Channel which needs to be linked to an Item and an Event Channel which cannot be liniked to an Item and is used to trigger rules.
Your rule above is using the Event Channel. Your log is showing events from a State Channel linked to an Item.
Well, you’ve posted a screen shot of the Channel. The little blue dot with the 1 in it shows it’s linked to an Item. Your events.log shows an Item named Hue_dimmer_switch_1_Button_Last_Event receiving state updates and changes.
Have you tried using this Item?
Indeed. Make sure to review the Getting Started Tutorial and the Concepts section of the docs. You cannot be successful with openHAB if you do not understand how bindings, Things, Channels and Items work together.
I spend hours reading over stuff to try and figure it out. It’s confusing for most of us, if it wasn’t for you many people like me would be in the dark. I still have not wrapped my head around Things, Items, and Models. (Yes read it many times) Maybe my thinking has calcified in an older world. In this case, I found the item. Probably last night looked for hue, looked for everything but Button Last Event.
Your answers are great, and I feel guilty.
Is there an age cutoff for posting to the community 
I might be there!!!
CDS
There’s no age cutoff but OH is complicated. If there are specific places where the docs can be improved, if it’s feasible, we like to hear. But it’s going to take some learning no matter what.
Home automation is hard.
As a “fresh eye” I see a few things. There are a lot of references to the docs. Contributors know the data is there because they are emersed in it. Newbies(me) search the docs using the search engine, or eyeball time, or google.
A doc engine search for Channels your get concepts, config, welcome and addons.
Eyeball time is just that. Most automation people just want to turn on a light making them impatient. (more accurately get on with it working)
Google floods you with older information.
I get it, I had 3 PhD’s, 2 human factors designers and 15 tech writers putting together switching system docs. It was very hard, not glamourous, and often times, a moving target.
You guys have done an outstanding job with volunteers. I hear the frustration in the contributors who answer the same questions over and over again. The community’s passion is great and you and your peers who contribute to “how it is done” are super valuable to us. The Blockly lead designer gave some videos where he had examples. They were excellent at explaining. What made them great is they were examples of what worked, you could use them and build on them.
In the docs world it’s quite common to have people not go beyond the examples they learned. Think emacs and vi. Most people only learned the basics from examples and never went beyond that unless they had to. How many people use spreadsheet every day and don’t know what a pivot table is!
So…my suggestion would be to standardize on a search template into the docs that have “examples”.
Glamours work, no way! If led by someone who could coordinate a core of use cases. Control a light, read a value, create a timed activity, log information, communicate message, etc etc. Maybe 20 use cases that hit 80% of the average needs. Then let’s say you have a finite set of things, items, and a model house. The examples use only the things defined within the use cases. The items use the same set of things, but different channels, or in a different way. Everyone works off the same model. Each use case becomes ever more complex using more and more capabilities. The documentation would say things like “as shown in Example 3.2.”, or reference ex3.2.
I did this when I had a 35 person help desk. Everyone was trained to call the helpdesk, so the staff kept growing. I took it over and reduced it down to 7 by formalizing examples of everyday things.
It may not be feasible in an open development environment. Like I said, it is not glamourous in anyway. New is funner!
If I had an indexed listing of all your posts, I wouldn’t need new docs. You have probably answered everything at least once, with an example!
I’d be happy to contribute in any way I could but I’m dog food, chief chow chow. nobody. I’d still be willing to help for all the future newbies yet to dive in! When you create a volunteer group, I’ll sign up!
Cliff
The docs have two main parts: The tutorials and the reference.
The reference is very amenable to searching to find just that part you need and can move on. But you are never going to learn the basics that way. That’s why the Concepts and Getting Started Tutorials exist. The former explains the basic concepts of OH and what their purpose are: Things, Items, Rules, etc. The latter shows how to create/configure/use each of these concepts from end-to-end.
If you skip Concepts and Getting Started, you won’t know how to interpret and use or even what to search for in the reference.
There are tons of examples in Getting Started. In fact it’s mostly made up of examples.
But as hard as it is to keep the reference docs up to date with changes in OH, it’s triply challenging to do so with lots of examples. From a manpower perspective, it’s not really feasible to do this.
But we do have:
In the abstract it sounds doable. But, especially when you start working with bindings and Things you run into trouble. What sort of light? A Hue bulb? Zigbee light switch? KNX relay? Tuya bulb accessed through MQTT?
Each of these will be very different at the Thing configuration level. So do we now have that one “Control a light” exploded in a dozen different use cases? Or do we pick one and use that is an exemplar? NOTE: Getting started picked the one as the exemplar approach (three really, simple Things, moderate Things which requires some manual configuration, and advanced which requires all manual configuration).
That was the original intent of Getting Started. In fact it was going to build the system you see when you go to the online demo. But:
There are nearly 400 add-ons to OH. We can’t create examples that cover them all. So the best we can do is present some exemplars that demonstrate the basic concepts and the end users will need to learn and apply that to their unique requirements. And hence the existence of the three tutorials for Things in Getting Started. Three examples to cover the three general ways that Things can be discovered and/or created.
But, once we’ve already lost the reader because they use Zigbee instead of Zwave and the intermediate Things tutorial uses Zwave as the exemplar, what value is there in keeping with Zwave all the way through?
It also doesn’t matter and that’s kind of the point of both Getting Started and the Concepts part of the docs. Once you have your Things and Channels done it’s all the same. A Switch Item connected to a Hue Light is the same a Switch Item connected to a KNX relay is the same as a Switch connected to an MQTT Channel. The Items are created the same way no matter what they are linked to. They are used no matter what they are linked to. They appear on the UI no matter what they are linked to.
Without that understanding OH is going to be really hard to use. And without that understanding, unless someone were to write 400! different tutorials for each used case (400! = 6 followed by 868 zeros) there’s always going to be someone left with “my use case isn’t covered”.
What needs to happen is someone reviews the intermediate Things tutorial and is able to use that as a template to install and configure any binding/Thing that requires manually configuring a Bridge Thing (which is almost all of them frankly without getting hung up on the fact that the tutorial covers Zwave but not [insert my binding here]. That tutorial teaches everything you need for bindings as diverse as Zigbee, OpenWeatherMap, Mail, Telegram, etc. They all use the same approach:
At this point everything else is always the same because all Items always behave the same way and the rest of OH pretty much only uses Items for everything.
What isn’t feasible is keeping them up to date in the long run. What this approach misses is making sure the end user understands that even if their one specific case isn’t covered exactly in the docs explicitly, the information needed is there. And it’s definitely no feasible to cover every or even a significant percentage of use cases, at least at the Thing level.
All my posts are searchable. And I have in the past written generic tutorials that I point people to to answer the common questions. But with the advent of MainUI, I have fewer and fewer situations where those apply or those answer the questions asked. Usually I’m helping with something very specific which doesn’t have a generic answer. But if you look at me postings in Tutorials and Solutions, particularly the Design Patterns, you’ll find most of them.
Thanks for the generous reply. I regret not being able to communicate what one may face at the onset. But thanks for the guidance as always.
There was a youtube video on OH2. The example had No Hue, no Zigbee, no Zwave. He went from install-config-binding(weather)-things etc to a simple rule. It could not fail in any way. One could see progress. When I started, I didn’t have a hue so I tried Zigbee. My /dev/tty never showed the example data. Thus, I could never add a thing so I spent days researching how to upgrade firmware on the dongle(rat hole). Simple - required a Hue bridge; Intermediate - required a zigbee dongle and if neither of those worked; dead in the water. The youtube saved me because I got somewhere with easy.
That was my only point in suggesting use cases. Get off the ground with something. As you said it’s complicated, but I think simple stuff should be easy and grow more complicated with time.
And I did give praise for the work you guys have done and also understand the impracticality of blanket level changes or updates. I spent 40 years swimming in this stuff. Know all too well what it takes even when you have “paid” employees! As you suggested, I went back and looked at concepts again, the text makes more sense when viewed against the backdrop of experience with OH and some of your pointers. Therein lies my perspective.
As always, thanks for the generous use of your time and understanding!
Plugging along
Cliff
I was pushed away from that approach. Originally I wanted to use bindings that had no external requirements (e.g. Astro, maybe a weather binding, stuff like that) but it was deemed better to use as examples the sorts of things real users will want to do instead of these “hello world” types of examples.
And they have a point. Getting Started serves two roles. It teaches how to use OH and it shows what OH can do. If we only show sun events and weather stuff, well where’s the home automation in that?
There are always competing goals and audiences and opinions. Sometimes what you end up with after balancing everything is not going to work for everyone.
…and when you have your things and items and a rule that is triggered via your button group then you can use the contextualInfo block (section Run&Process) to get the triggering item;
Sorry I didn’t get back to you sooner, I’ve been working on an aircraft panel with a problematic can bus and no tools to debug. Suspecting noise on grounds
It’s all valid stuff. I think I might have told you I used to run a lot of focus groups after seeing a video of an apple focus group. The mouse was symmetrical and because prior to that most “appliances” had the cords coming out of the bottom (think razor, mixer) the test subjects started moving the mouse and said “Wow, that’s odd, you move left it goes right, right it goes left”. Apple later redesigned the mouse to have the familiar hump you see today.
There is a minimum requirement for getting started in OH. I think it flushes out the weak, but the community is grateful you have the knowledge and the temperament to be so helpful to the test subjects!
Thank you, BTW, loving the interface. Crawling my way up more and more functionality.
This should be the way of the world. I want my Alexa echo to sense my presences in the house and tell me that I left the garage door open when it is after 10pm.
I even want AI to answer me which day of the week is a good day to fly and if I agree add it to my Calander.
For now, lightbulbs…
So many automations, so little time!!!
Cliff
I’d like as a question that I can’t find the answer to and my experiments are not working.
When adding an action what is the preferred method?
Add the script by name or by ID here or here?
Design the rule and use the “run rule or script” and enter the name.script or in my case a long number assume script id 688aa10b68 which didn’t work?
Or, copy the code directly and place into the rule?
I’ve tried all?
cds
I’d like as a question that I can’t find the answer to and my experiments are not working.
When adding an action what is the preferred method?
Add the script by name or by ID here or here?
Design the rule and use the “run rule or script” and enter the name.script or in my case a long number assume script id 688aa10b68 which didn’t work?
Or, copy the code directly and place into the rule?
I’ve tried all?
cds
I’m not sure what you are asking.
The two fields you are pointing to are informational only. They are a great place to document what the Script Action does, add keywords to make it easier to find later, etc.
If you are trying to call a rule from another rule (the only thing I can think of where you’d need to enter a rule UID) you have two options (more than two really as all but Rules DSL support that too).
You shouldn’t be manually entering the rule ID anywhere. You select them from the list and the list shows the name of the rule, not the UID.
Though as an aside I recommend giving the rules a meaningful uid when you create them too.
Here you will need to manually type in the rule UID.
But none of that has anything to do with what @Larsen posted.
Keep in mind that a “Scene”, “Script”, and “Rule” are all stand alone independent Rules. Scene and Script are just special cases. A Scene is a rule that just consists of a list of Items and the states you want to command those Items to when the Scene runs. A Script (i.e. Settings → Scripts) is a rule that consists of only of a single Script Action. There are no triggers and no conditions (i.e. but only if…).
A generic Rule can consist of one or more of the following:
You can define an inline script for the actions or conditions in which case they are called Script Actions and Script Conditions. Script Actions/Conditions do not exist independently. These cannot be seen nor interacted with except within the rule where they are defined.
This is all supposed to be explained in the Concepte → Rules section of the docs and demonstrated in Getting Started.
If you happen to have a block of code you want to reuse across multiple rules, it’s somewhat possible to define it as a Script (i.e. Settings → Scripts) and then use the two approaches above to call that Script. But there are limitations and dangers in doing that.
But I’m not sure what this has to do with getting the triggering item name.
Thanks, I’ll go through it today. This is what I get…
It’s already been renamed that in 4.1
That’s where you’d write the action as part of this Rule. If you need a rule to do something complicate this is going to be what you do most of the time. Having a rule call another rule is going to be a rare case.
It’s discussed in Rules | openHAB, and in Rules - Introduction | openHAB which includes a discussion of the difference between a Script and a Script Action.
Calling a rule from another rule is demonstrated at Rules - Scenes | openHAB in the context of a Scene since MainUI doesn’t have a way to add a trigger to a scene directly.
still need to be inquisitive… Are there any updates???
I don’t understand the question. Updates to what?
